AMD Alleges Intel Compilers Create Slower AMD Code

edxwelch writes "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.""

Comments

How can this be done?

[haluness]

Not being a compiler or chip guru, how does one work out that a compiler favors a specific chip? I can understand that it might be easy to detect code that looks for a specific chip, but then how do they determine that the resultant code is being optimized based on that detection?

Re:How can this be done?

[the_weasel]

Which is exactly what we did when we discovered this. And sure enough, when the Intel compiler thought our AMD was a Genuine Intel certain functions increased dramatically.

The company I work for submitted a few reports on this a few months ago, as I am sure did many others. I am very pleased to see them following up on it.

Re:How can this be done?

[saigon_from_europe]

And sure enough, when the Intel compiler thought our AMD was a Genuine Intel certain functions increased dramatically.

How did you make it believe it was Intel, not AMD?

My company writes some code that depends on SSE2 instructions. We bought one AMD (64-bit) machine, but code was slower on Athlon64 3200 than on P4 3000 (under WinXP, not on some 64-bit system). We heavily depend on every tact, so I would really like to know how to trick Intel's compiler to believe that AMD is P4.

Where is all this going

[1967mustangman]

I am huge AMD fan myself, but this has me a little worried. If they can really prove their claims great for AMD, but if not I fear they risk looking like SCO and becoming the brunt of many jokes.

It's true--and they know about it

[Eponymous Cowboy]

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++.

Re:It's true--and they know about it

[bitplayer]

While the focus of these threads is Intel vs. AMD competition, I think that it is worth pointing out that Intel is also crippling (or, at least, "not improving") the performance of their own PIII processors. For what reason would anyone do that, other than an desire to sell more P4 processors when a PIII processor might suffice?

Re:It's true--and they know about it

[justforaday]

Remember how all the benchmarks put the P3 ahead of the P4 (clock for clock) when the P4s debuted? It seems this little trick of theirs could cause developers to say "Wow, the P4 really is fast compared to the P3."

Re:Simply ludicrous

[RootsLINUX]

Well, I don't think they would make such a claim without at least some sort of evidence. And we all know that Intel is a corporation that doesn't like to play nice with the other kids. During my senior year of undergrad my computer architecture professor consistently refered to Intel as "the evil empire", so who knows. I'd like to see AMD present some hard evidence though.

Re:Wouldn't We Notice It?

[digidave]

Not to mention the fact that AMD still benchmarks very favorably in games and other CPU-intensive applications, so the slowdown can't be huge.

However, I doubt AMD would claim this if it weren't true. They still have a business to run, unlike SCO, and don't want to damage their reputation.

I suspect that the "crash" part is more conjecture than fact, since the unoptimized code paths might be assumed to be lower quality in many ways. Or perhaps AMD found a single instance of a crash that occurs in one of the unoptimized code paths and even if Intel didn't mean for it to be there, they're still on the hook for that path in the first place.

I have a feeling AMD has been working on this lawsuit for several years, so it will be interesting when they do finally submit the evidence to the court.

as someone who worked at a compiler company

[MatD]

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.

Re:Oh brother

[tshak]

Intel doesn't come close to a monopoly in the compiler market, so I fail to see what this has to do with the antitrust suit.


That's because you're trivializing the issue. Intel has a chip monopoly their compiler has a huge influence - even if it isn't used in production by the majority of their customers. Purposely reducing the efficiency for AMD chips is a great example of anti-competition, which is what monopoly laws are all about.

Work on GCC!

[XanC]

Maybe they will have to use their own [compiler] (after they make it).

Come on, AMD... If you do need to do your own compiler work, optimize GCC! The whole idea is to make code run fast on your chips, right? And think of the tremendous goodwill you'd build up, especially around here.

Re:Simply ludicrous

[yomahz]

Yes but, they knew enough to block W3C's validator from their site:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .slashdot.org%2F

Re:The Limit of Lawsuits

[mog007]

If they put a warning in the EULA for the compiler about it not being efficient in non-Intel processors, then Intel would definitely be in the clear, but if they sold their product as simply a vanilla x86 compiler, then they've got shit to be responsible for.

Re:Compiler + host platform + target platform comb

[Renegrade]

Most Linux development is done using GCC , Most of windows with MSVC++. Only true hard-core inner-loop optimising geeks usually use Intel C/C++ compilers. These are people like game devs, crypto developers and HPC programmers.

I resent that. I optimize my inner loops (and the outer loops, and even the startup initialization data is cache aligned...) and develop games and I use MS VC6 for Windows and GCC for Linux/*BSD* exclusively.

What sort of silly person would expect an INTEL compiler to generate decent AMD code anyways? While I didn't expect intentional sabotage, I'm not entirely surprised either. It's not like it's in Intel's best interest to spend millions on creating an optimizing AMD compiler.

Link

[rangek]

This seems to be it. I haven't tested it yet.