Intel Stinks, Again

First, from Slashdot

In AMD’s recient anti-trust lawsuit AMD have examined the Intel compiler and found that it deliberatly runs code slower when it detects that the processor is an AMD. “To achieve this, Intel designed the compiler to compile code along several alternate code paths. … By design, the code paths were not created equally. If the program detects a “Genuine Intel” microprocessor, it executes a fully optimized code path and operates with the maximum efficiency. However, if the program detects an “Authentic AMD” microprocessor, it executes a different code path that will degrade the program’s performance or cause it to crash.”

An interesting comment:

Look, the issue is this:

* There are AMD processors that support MMX, SSE, SSE2 (Intel Processor extensions)
* The Intel Compiler is a widely used one for a segment of developers.
* The compiler should create code which will use any and all of Intel’s own optimizations( MMX, SSE, SSE2 )
* The compiler will do this for Intel Processors.
* The compiler will not use those very same extensions/optimizations when it detects an AMD cpu.
* Those extensions are implemented by AMD to INTEL’s specifications(licensed from them).
* The compiler SHOULD make use of them.
* They are NOT AMD specific extensions/optimizations.
* The allegation is that INTEL made their compiler to work properly when compiling for INTEL chips, but not use ANY optimization extensions(intel or otherwise) when it detects an AMD chip.

The compiler doesn’t need to be optimized for AMD’s chips. But it does need to be optimized for extensions which Intel supports. The claim is that Intel’s compiler DOES NOT support their own extensions when an AMD chip is detected.

This is important because the Intel Compiler is used to compile benchmarks, enterprise level code, demonstrations, etc. Business decisions to go with one chip or another are based on the performance of the software, which was compiled from the Intel Compiler, which claims to be able to support the INTEL extensions.

By crippling the resulting code when the compiler detects an AMD CPU, Intel is essentially LYING about the performance of their processor and about the performance of the AMD processor through resulting benchmark software(s) and applications compiled with the Intel compiler.

Yes, AMD can make their own compiler, but people have to choose to use it. People who are already using the Intel compiler invested time and money into creating a development environment based on it. Switching isn’t easy. If the compiler makes the AMD cpu look bad, businesses will choose to go with Intel thinking those processors gave them better bang for their buck, when the opposite might be true.

It’s like having two cars that can do 125MPH, but one has been electronically locked to max out at around 85MPH, then putting them on a racetrack to determine which car is faster.

That isn’t a valid comparison. And if INTEL’s compiler IS purposefully generating substandard code that doesn’t even support their own extensions in AMD’s cpus, then benchmarks compiled with the Intel compiler are similarly invalid.

This could also mean contractual violations between AMD and INTEL since AMD licenses the enhanced extensions from INTEL.

It ISN’T about INTEL’s compiler not optimizing itself for AMD specific instruction sets. It is about INTEL’s compiler not optimizing itself for INTEL specific extensions on AMD CPUs, which AMD has license from INTEL and implemented in their processors.

Another way of looking at it is that AMD has licensed enhancements believing that INTEL’s compiler will similarly take advantage of those enhancements. Perhaps that was in the agreement, perhaps not.

If it was the case, then AMD should be furious. They basically licensed and implemented extensions, from INTEL, into their processors that INTEL is choosing to not support. Not because it isn’t compatible, the extensions were implemented to their specifications, but to be anti-competitive and deceptive in the intent of their licensing of the extensions.

A simple: if ( intel cpu) { optimized code + extensions } else-if ( amd cpu ) { standard code w/o extensions} is overly simplistic for an engineering organization like Intel and would be difficult to explain away since they are licensing their extensions.

The compiler should be checking for the existence of extensions and choosing to compile in functionality or not. Most games and graphics packages use dynamic libraries and alternate blocks of code for different extensions detected. If small, mid-sized, and large game companies can do this… why can’t INTEL?

It isn’t a resource issue. It isn’t an intelligence issue. It surely isn’t an oversight issue since they have a horde of lawyers watching over what goes on.

What it will come down to will be a question of simple negligence or outright malice. Either outcome has INTEL coming out looking worse for the wear. Either outcome has AMD coming out looking better.

A third outcome is that AMD’s case fails. But even if their case does fail, I would imagine the case will bring alot of questions up with businesses and investors regarding the trustworthiness of INTEL’s compiler and the code it generates.

Some people like to side with Intel:

as someone who worked at a compiler company (Score:5, Interesting)
by MatD (895409) on Tuesday July 12, @12:03PM (#13043193)
I know how this can happen (and it has nothing to do with being evil).
The engineers get the specs for the next version of the compiler. They also get a slew of bug reports from the last version. They have a short amount of time to impliment the new specs, and fix the bugs.
The bug reports will be something like, “on AMD processors when doing a memcopy with optimization xyz turned on, the processors mispredicts half the time. This makes it very slow.”
The engineer in that case, turns the optimization off for that generated code, thereby ‘fixing’ the bug (but not really). It happens all the time.
It’s not a nefarious plot, it’s the same time crunch issue that every software engineer has to deal with.

And there is rather substantial evidence that the allegation is true:

It’s true–and they know about it (Score:5, Interesting)
by Eponymous Cowboy (706996) * on Tuesday July 12, @11:43AM (#13042922)
I noticed this problem back in January of 2004, with Intel C++ 8.0, and went through heck over nine months with Intel’s customer support to get it fixed until I eventually had to abandon their compiler.

On any non-Intel processors, it specifically included an alternate code path for “memcpy” that actually used “rep movsb” to copy one byte at a time, instead of (for example) “rep movsd” to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I’d ever seen, and was around 4X slower than even a typical naive assembly memcpy:

push ecx
shr ecx, 2
rep movsd
pop ecx
and ecx, 3
rep movsb

They responded with completely ridiculous answers, such as:

“Our 8.0 memcpy was indeed optimized for a Pentium(r)4 Processor,when we reworked this routine we used the simplest, most robust, and straightforward implementation for older processors so that we didn’t need the extra code to check for alignment, length, overlap, and other conditions.”

BS. I went and added the following line to the beginning of my source code:

extern “C” int __intel_cpu_indicator;

then I added:

__intel_cpu_indicator = -512;

to the “main” function.

This forced Intel C++ to use the “Pentium 4” memcpy regardless of which processor in in the machine. It turns out that their special “Pentium 4” memcpy which I tested thoroughly in all kinds of situations, and it worked perfectly fine on an AMD Athlon and a Pentium III. I pointed this out to them.

I received the following response:

“The fast mempcy is over 2000 lines of hand coded assembly, with lots of special cases where different code paths are chosen based on relative alignment of the source and destination. … If the performance of memcpy/memset only are improved for Pentium III will that satisfy you?”

I answered “No,” saying that I needed support for AMD processors as well. I also gave them a copy of my own memcpy routine that was 50% faster than theirs–and just used MMX. They closed the support issue and did nothing to resolve it.

I switched back to Visual C++.

Interesting reads:
http://www.swallowtail.org/naughty-intel.html

Next, the Register

Japan calls Intel to task over anti-AMD rebates
By John Oates
Published Tuesday 8th March 2005 09:18 GMT

Intel is facing demands that it changes the way it does business in Japan or face court action.

Japan’s Fair Trade Commission (JFTC) has ruled that the company deliberately tried to limit AMD’s market share, by imposing restrictions on five of Japan’s biggest PC makers, which collectively account for 77 per cent of PC sales in the country.

We have a summary of the JFTC’s findings, courtesy of an AMD press release, namely that:

One manufacturer was forced to agree to buy 100% of its CPUs from Intel; another manufacturer was forced to curtail its non-Intel purchases to 10% or less;

Intel separately conditioned rebates on the exclusive use of Intel CPUs throughout an entire series of computers sold under a single brand name in order to exclude AMD CPUs from distribution;

The mechanisms used to achieve these ends included rebates and marketing practices that includes the “Intel Inside” program and market development funds provided through Intel’s corporate parent in the United States.

The JFTC has told Intel that it can no longer dole out rebates to Japanese PC makers on conditions that exclude competitors. Intel has ten days to respond to the JFTC, but says it continues to believe its practices are legal. It is deciding what action to take.

In a statement Intel expressed concern that Japanese regulator’s decision “does not appear to take into account antitrust principles commonly accepted worldwide”.

Bruce Sewell, vice president and general counsel for Intel, said: “One of the core principles of competition policy is the notion that such policies should be based on sound economics. There is a broad consensus that competition regulators should only intervene where there is evidence of harm to consumers. It is apparent the JFTC’s Recommendation did not sufficiently weigh these important principles.”

AMD has a different take on the ruling:

“The JFTC found that Intel illegally manipulated the market to exclude competition, hurting PC users around the world,” said Thomas McCoy, AMD executive vice president. “Using market power illegally to limit innovation and, more importantly, consumers’ freedom to choose, cannot be tolerated. We encourage governments around the globe to ensure that their markets are not being harmed as well.

“The evidence of harm to consumers is obvious. By preventing PC manufacturers from using CPUs of their choice, Intel’s misconduct deprived consumers worldwide of the freedom to purchase computers that best fit their needs. Efforts by an avowed monopolist to artificially set market shares to exclude competition clearly violates antitrust standards globally.”

Okay, let’s think about one more thing. Imagine how much time, money, and productivity has been lost because Intel has done this. Intel artificially made code less efficient for AMD processors, thus hurting every company and individual who uses these (better) processors.

Also worthy of note: Apple is going Intel. You’ll continue to pay a price if you, for some reason, want the ease of use that comes with a Mac.

When you buy a PowerBook, you’re paying for the aesthetics. When you buy an iPod, you’re paying for the name. The iPod is still hugely overpriced — that is a fact (that is especially easily seen when comparing with other music players). It’s popular because of the design and the name.