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

Another EXCELLENT reason to use open source..

[ylikone]

...software. Something like this would never be implemented in an open source compiler. With open source, you know exactly what you get... with closed, you get what the owners want you to get, which will help their bottom line.

Re:Another EXCELLENT reason to use open source..

[BadDoggie]

You've obviously forgotten (or more likely, never heard of) Ken Thompson. He was the guy that put the self-replicating backdoor in the UNIX compiler which, even if you removed from source, would be re-inserted if the compiler saw that you were compiling kernel or compiler.

He did it to show that the further down you go, the harder it gets to detect such things. So you wrote a new compiler to get around that? Great. How're you planning on compiling it?

Never forget that Open Source is no guarantee of security in and of itself.

woof.

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

[greed]

Intel is not detecting the supported instruction set, they are detecting the actual CPU.

The way a responsible compiler developer generates code in this situation is to say, "I need feature X, Y and Z for this code path--it will be used if all are present."

The only thing the latest Pentium IVs have on the Athlons is the SSE3 extensions, and that is pretty much irrelevant to most code. "It must be true, Intel told us."

If you switch the Intel compiler so that it does NOT generate multiple-CPU-supporting code, you can generate code that runs on Pentium III, IV, and Athlon just fine. (My overly-cheap ECS Duron board burned out, and who cares about Duron anymore anyway?)

(The magic switches are -xK or -xW, BTW.)

But there is no reason for code targetting a Pentium IV restricted to SSE2 at the highest to NOT run on an Athlon. You can "not support" it, sure, but to DELIBERATELY disable the code when you detect a competitor's chip is... well, anti-competitive.

And this isn't a free compiler. You pay for ICC. (There's a for-free-software download, sure, but most people who really care about this stuff are more than willing to pay, and pay well, for the best compiler optimizations they can get.)

The problem is not that they can't guarantee that the AMD chips work. The problem is they are generating instruction streams that run JUST FINE on AMD chips and their runtime code DISABLES that code path (if you use the recommended or default compiler settings).

It's AMD's job to make sure their implementation of IA32 + whatever extensions is good, not Intel's job to disable code on their chips--except based on the processor capability word. (Whatever "flags" from /proc/cpuinfo is properly called.)