One of the claims in AMD’s sensational antitrust complaint against Intel has been getting some play around the web lately. Specifically, folks are focusing on what AMD says about Intel compilers and how they react to the presence of AMD processors. Here’s the meat of the claim, taken directly from the AMD complaint:
Intel has designed its compiler purposely to degrade performance when a program is run on an AMD platform. To achieve this, Intel designed the compiler to compile code along several alternate code paths. Some paths are executed when the program runs on an Intel platform and others are executed when the program is operated on a computer with an AMD microprocessor. . . . 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 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.
So AMD says Intel is sabotaging its CPUs with iffy compiler behavior.
We do use some benchmarks compiled with both the Intel and Microsoft compilers, such as LAME MT and Sphinx, just to see how different compilers affect performance. However, we couldn’t verify or dispute AMD’s claims based on that limited experience.
A gent named Mark Mackey has spent some time with Intel’s Fortran compiler for Linux, and his experiences would seem to back up AMD’s claims. (Thanks to Per Olofsson for the link.) After a bit of testing and looking into Intel’s CPU identification routine, he comes to this realization:
The code produced by the Intel compiler checks to see if it’s running on an Intel chip. If not, it deliberately won’t run SSE or SSE2 code, even if the chip capability flags (avaialble [sic] through the ‘cpuid’ instruction) say that it can. In other words, the code has been nobbled to run slower on non-Intel chips.
He then checks with Intel for a fix, looks at several version upgrades, and the problem basically persists. His solution? Patch the compiler to sidestep the CPU check, and run a few quick benchmarks. He finds that “patching out the ‘GenuineIntel’ check makes no difference to the P4, but increases the performance of the Opteron by up to 10%.” Yow.
His conclusions are sharply worded:
To Intel: there is a standard mechanism out there (invented by you!) for questioning a CPU as to its capabilities. You should be using that, not checking for the presence of your trademark. I don’t expect Intel to support AMD-specific extensions, and I also don’t expect Intel to have to test its compiler on AMD CPUs. However, if a CPU states that it can do SSE3 or whatever then I expect the code produced by the Intel compiler to use SSE3 instructions rather than to check first if the chip was made by Intel.
Perhaps Mr. Mackey is secretly an AMD partisan, but he seems to have done his homework. One wonders whether the Intel compilers’ SSE limitations on AMD processors extend beyond the Fortran compiler for Linux. This post on Slashdot would seem to suggest problems in the C++ compiler, as well.
Share
