Slashdot Log In
AMD Alleges Intel Compilers Create Slower AMD Code
Posted by
CmdrTaco
on Tue Jul 12, 2005 10:39 AM
from the getting-a-little-spicier dept.
from the getting-a-little-spicier dept.
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.""
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Simply ludicrous (Score:5, Funny)
That is an outragous claim! No company would stoop so low. Why, that would be like claiming that Microsoft configured its servers to give broken HTML to browsers other than Internet Explorer. That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. That would be like saying that Adobe publishes pdfs that b0rk XPDF.
Anybody can see that this claim is ludicrous and that things like this just don't happen. (but I hope I'm not giving anybody any ideas.)
Type your currency conversion into a free form text box
Re:Simply ludicrous (Score:5, Funny)
Parent
Re:Simply ludicrous (Score:5, Funny)
Parent
Regulators Raid Intel Offices (Score:5, Informative)
They'll probably be convicted and then buy the regulators like MS so they only get a slap on the wrist.
On that note, was there *anything* negative that came of the Microsoft monopoly ruling?
Parent
Re:Regulators Raid Intel Offices (Score:5, Funny)
Well for starters, Microsoft is still here.
Parent
Re:Simply ludicrous (Score:5, Interesting)
Parent
Re:Simply ludicrous (Score:5, Funny)
>> without at least some sort of evidence
We agree.
- darl
Parent
Re:The Limit of Lawsuits (Score:5, Insightful)
1. AMD's claim is that the Intel Compiler produces code that actively detects the AMD CPU, then intentionally runs slower code. That's not the same thing as Intel optimizing their compiler for the Pentium Architecture.
2. If you think the SPARC is a poorly designed processor, you need your head checked.
By restricting the GCC compilers to generating only a simple but fast subset of instructions, we could encourage both AMD and Intel to deprecate and, ultimately, eliminate the more complex x86 instructions. Linux and the bulk of open-source software use the GCC compilers and would provide a critical mass of support for a new streamlined transistor-count-reduced x86 chips. Here, I am thinking, "shockingly reduced in power due to using 1/3 of the transistors."
Wouldn't that make the x86 Platform act like one of those "Poorly Designed RISC Processors" you were just complaining about?
In any case, you won't see much of a transistor reduction. Most of the instructions you're trying to avoid are implemented in MicroCode and add no significant overhead to the chip. What *does* add all the transistors is the 20 stage pipeline, branch prediction, superscalar execution, Out Of Order instructions, etc, etc, etc.
Parent
It's true--and they know about it (Score:5, Interesting)
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.
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 (Score:5, Funny)
And when a Microsoft product is the lesser of two evils, you know for sure that there's something fishy going on.
Parent
Re:It's true--and they know about it (Score:5, Funny)
push parent, @AMDsubpoena_list
Parent
I do that ... (Score:5, Funny)
profit!
This is old news, however Intel EU raid today... (Score:5, Informative)
However, what's news, is that EU antitrust investigators raided Intel and some OEMs today...
http://theinquirer.net/?article=24554 [theinquirer.net]
They probably were hunting for some documents related to alleged antitrust violations - nice free additional ammo for AMD and their case, methinks...
Another EXCELLENT reason to use open source.. (Score:5, Insightful)
Relevant Section (Score:5, Informative)
c. Intel's Leveraging of Its Other Product Lines to Unfairly Disadvantage
AMD in the Marketplace
122. Intel has also designed and marketed microprocessor-related products with the
goal of compromising performance for those who opt for AMD solutions, even if it requires
sacrificing its own product quality and integrity.
123. An example is Intel's compilers. Generally, independent software vendors
("ISVs") write software programs in high-level languages, such as C, C++, or Fortran. Before
these programs can be understood by a computer system, they must be translated into object
code - a machine-readable language - by a software program called a compiler. Different
companies write compilers for different operating systems (Windows, Linux, etc.) and for
different programming languages (C, C++, Fortran, etc.). Intel offers compilers for use with a
variety of different operating systems and programming languages.
124. Intel's compilers are designed to perform specialized types of optimizations that
are particularly advantageous for ISVs developing software programs that rely heavily upon
floating point or vectorized mathematical calculations. Such programs include, for example,
mathematical modeling, multimedia, and video game applications.
125. 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. (The choice of code path is determined when the program is started, using a
feature known as "CPUID" which identifies the computer's 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 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.
126. ISVs are forced to choose between Intel's compilers, which degrade the
performance of their software when operated with AMD microprocessors, or third-party
compilers, which do not contain Intel's particular optimizations. Sadly for AMD and its
customers, for legitimate reasons Intel's compilers appeal to certain groups of ISVs, especially
those developing software programs that rely heavily on floating point and vectorized math
calculations. Unbeknownst to them, performance of their programs is degraded when run on
an AMD microprocessor not because of design deficiencies on the part of AMD, but
deviousness on the part of Intel.
as someone who worked at a compiler company (Score:5, Interesting)
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:How can this be done? (Score:5, Informative)
For example, you write some code that would typically use SSE2 regisers when compiled, then you compile the code for each processor, and check to see if it used SSE2 registers on each, or if it ouput slower "emulation" style instructions on the AMD.
Parent
Re:How can this be done? (Score:5, Interesting)
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.
Parent
Re:How can this be done? (Score:5, Informative)
Parent
Re:It's called good business (Score:5, Informative)
Parent
Re:Where is all this going (Score:5, Funny)
Well, they do require quite a lot of cooling, don't they?
Parent
Re:CmdrTaco == automated script (Score:5, Funny)
Parent
Re:Never (Score:5, Insightful)
Now ask yourself again: do you believe that it's PURE COINCIDENCE that Intel's compiler produces slow code for its competitor's processors? Code that even a novice Assembler programmer would be able to improve instantly (see the rep movsb vs. rep movsd issue mentioned in a comment above, for example?) Do you believe that, for some funny reason, they never happened to notice? That noone ever complained to them about it? That they're really just an innocent victim here?
Well, do you? If yes, please get back to me, I have a used car to sell you.
Parent
Compiler + host platform + target platform combo.. (Score:5, Insightful)
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.
So yeah, there's a lot of code that doesn't work with Amd64 when compiled with ICC. But how many people build stuff on Amd64 with an Intel compiler ?. (remember this is not valid for stuff compiled on a pentium 4 but running on amd64)Parent
Re:What's surprising about this? (Score:5, Informative)
If they intentionally bloated the machine code for AMD processors, then that is wrong.
If you RTFA you'll see that AMD is charging (and numerous sources are confirming) that Intel did extra work to specifically make things slower when programs compiled with their compiler were run on an AMD. On previous poster even posted his two line partial fix for the issue that drastically improved code speed and which he gave to Intel while trying to solve this issue with the compiler. Basically it just tricked the compiler into always using the copy function for Intel processors. This was obviously malicious.
Parent