AMD Alleges Intel Compilers Create Slower AMD Code 912
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 is not news (Score:2, Informative)
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?
Re:How can this be done? (Score:2, Informative)
Usually by decompiling the code produced. AMD probably made a test program, compiled it, found a chip test routine in the resulting binary, then decompiled the 2 code paths it could follow.
For example, the "intel" code path could, for example, make full use of the math coprocessor to perform a division, while the "non-intel" code path could use only the 16 bit registers and make multi-precision divisions with only the basic x86 instruction set. I'm sure the actual de-optimization (if it occured) involves higher, cleverer functions than just divisions, but that's the general idea.
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.
Re:How can this be done? (Score:4, Informative)
Also, the lawsuit claims that Intel's compiler wont use x86 ISA extensions such as SSE2 even when they're available on AMD processors. There is a reason we have these kinds of ISA extensions, and it is becaue performance is much much better when you use them.
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...
It is semi true (Score:1, Informative)
It does not target AMD negatively, but rather targets Intel positively. There is a huge difference.
When the compiler runs into a "genuine Intel" CPU it knows exactly how to compile the code paths to get the maximum performance. When it compiles everything else it needs to take the "safe" route and compile it as best it can (sometimes not very good at all)
Not a deliberate attack on AMD but rather a boost one would expect from a company that is providing a compiler and CPU's.
Wouldn't you expect an AMD compiler to take advantage of EVERY possible tweak it could to make code compiled for AMD processors run faster? Why call Intel the devil for doing the same thing?
Re:Never (Score:2, Informative)
Re:How can this be done? (Score:2, Informative)
Re:So.. wait (Score:3, Informative)
Re:It's called good business (Score:5, Informative)
libstdc++, Cygwin and GCC = slow (Score:1, Informative)
Re:How can this be done? (Score:1, Informative)
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.
Re:How can this be done? (Score:5, Informative)
Re:Wouldn't We Notice It? (Score:3, Informative)
The story is light on details and doesn't say if the compiler is generating code optmized for the P4 or if it's code supposedly optimized for the AMD or if it was one of those "blended" things. If it's optimized for P4, then I can easily see how intel's instruction ordering can be beneficial for them, and slow the AMD.
Things like pipeline length and differing branch predictors can cause wildly different results on different CPU's.
I really don't see how Intel is under any obligation to optimize their compiler for AMD.
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.
Re:Instruction timing??? (Score:5, Informative)
No, if it was using proprietary 'processor specific improvements (TM)'.
However, it is *not*.
The real answer (not Intel's answer), is Yes, because Intel's compiler (which is widely regarded as producing some of the fastest binaries out there) produces code that will only take advantage of standard processor extensions (MMX, SSE, SSE2, SSE3) on 'Genuine Intel' Processors. Regardless of whether or not AMD processors support these extensions, the code excutes in slower, emulation mode if it does not detect 'Genuine Intel'.
When you 'fake' the compiler out by having all processors return 'Genuine Intel', the compiler generates code that will utilize standard extensions that it recognizes (everything but 3DNow, and 3DNow-2), on *any* processor that supports them.
This means your athlon will run SSE code, and your athlon 64 will run SSE,SSE2, and SSE3 code.
Not to mention MMX code, which Intel even disables for non-Pentium 4 Intel processors, even though Intel processors have supported MMX since the Pentium MMX!
This kind of manipulation is clear, and the only purpose is to portray the Pentium 4 as superior, and both older Intel processors and all AMD processors would appear siginificantly faster if the compiler simply utilized whatever extensions where avaliable (on the order of 10-40% for some programs) rather than relying upon the 'Genuine Intel' flag.
Intel *is* a monopoly, and although it is not illegal for a monopoly to exist, monopolies, under current U.S. law, are not permitted to use predatory tactics, especially when going from one market to another (compilers->processors).
Re:Send that to AMD's legal team! (Score:3, Informative)
The story here is the marketing practices... (Score:5, Informative)
You should really read this, it's pretty amazing. After AMD offerred HP 1 million processors to compete with Intel Retaliation, Intel upped the stakes, and HP backed down.
I for one am VERY scared about the new Apple Intel adoption. I've always been an AMD fan, but prices of late, as well as difficulting getting "approved" systems for my video editing software has made me purchase Intel for my last 2 machines. (Though I type this on a barton 3000).
I don't think Intel has been driving the innovation bus, and if you thought Microsoft was the bad guys, I have a feeling you aint seen nothin yet.
Re:How can this be done? (Score:3, Informative)
This assumption is wrong
see here [bell-labs.com] and here [bell-labs.com]
if it wasn't for licensing hiccups the plan9 c compiler would be OpenBSD's default by now
"I am sorry for the strong minded way in which I am approaching this,
but I am very dissapointed [sic] that after years of requesting that the
plan9 c compiler become free so that we can start extending it and
working with it... that we could be rebuffed in such a way because the
lawyers have not been properly reined in." Theo de Raadt [psu.edu]
Re:Simply ludicrous (Score:5, Informative)
Intel Fortran Compiler works fine for me on AMD (Score:2, Informative)
Re:Regulators Raid Intel Offices (Score:2, Informative)
Re:Where is all this going (Score:4, Informative)
Re:Another EXCELLENT reason to use open source.. (Score:4, Informative)
Read Ken Thompson's classic paper on just that. He makes the case that it would, in fact, be not terribly difficult to hide code that does exactly what intel is being accussed of in an open source compiler, without anyone ever knowing it was there.
Re:How can this be done? (Score:4, Informative)
Re:How can this be done? (Score:5, Informative)
Re:Before we damn Intel (Score:4, Informative)
The Compiler produces MMX, SSE, SSE2, and SSE3 optimized code, but will revert to emulation and pure integer/floating point processing if it does not detect 'Genuine Intel' and 'Pentium 4'.
It's not a question of producing optimal code in terms of processor configuration; that's a gimme. Its a question of not even permitting competitor processors to utilize standard processor extensions, including *older* intel processors that support a partial subset of those features.
Athlon 64s, by the way, support all of these, and operate perfectly, if they are tricked into reporting 'Genuine Intel'.
AMD is not asking Intel to have the compiler produce code that takes advantage of the Athlon architecture; there could be different optimizations because of the Athlon's better memory architecture, or lesser penalty for misprediction, and shorter pipeline.
No, AMD is asking that Intel not produce a compiler that intentional disables standard processor extensions for non-Pentium 4 processors.
Re:Simply ludicrous (Score:2, Informative)
Wow.
That process of rewriting the code to standards was not only a pain in the butt, but it also broke it on IE. This was one of my many aggravations while working at that job (that and traversing the byzantine bureaucracy (cool... alliteration)). Microsoft goes off on their own weird tangents with IE and throws the standard to the wind, while Firefox sticks with it, but at the same time is choking itself because very few sites out there write to standards.
Re:Simply ludicrous (Score:1, Informative)
please show us what compilers you have developed that take full advantage of your oh-so-superior CPUs.
Well?
Nothing, huh?
Not even one fucking compiler.
Thought so.
Re:Simply ludicrous (Score:5, Informative)
If you're too lazy to read the postings here shows such evidence. [slashdot.org]
It's an example showing the poor assembly-language code when it detects an AMD chip. And notice in that posting that the complier is perfectly capabile of producing efficient AMD code as well. It's sad but funny that the workaround to produce fast code for the AMD chip is to add the string "__intel_cpu_indicator=-512".
Re:Compiler + host platform + target platform comb (Score:4, Informative)
There are a lot of companies who take performance very very seriously. We are just one of them.
The problem here has nothing to do with crashing, it has to do with the problem that companies that have chosen the Intel compiler for it's excellent performance suddenly find themselves producing software that is much slower on AMD systems than it needs to be.
The options are to switch to a different compiler and take the performance hit that comes from that (which can be quite significant) or put pressure on Intel to stop trying to 'innovate' using underhanded tactics.
Since we can hack around the problem for now by tricking the compiler into thinking our AMD is a Intel, I choose to try pressuring Intel before we try switching.
Re:I have to post anonymously (Score:1, Informative)
Re:The Limit of Lawsuits (Score:3, Informative)
That's patently not true [wikipedia.org]
Sure are alot of people not RTFA'ing. (Score:5, Informative)
Look, the issue is this:
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 thi
Re:Write Your Own Damn Compiler, AMD! (Score:5, Informative)
Hey, maybe instead AMD could pay people to work on GCC. Oh, wait, they do that already. Why do you think GCC was ported so quickly to AMD64? GCC development is not, AFAIK, funded much (if at all) by the FSF anymore. It's all Apple, AMD, IBM, the various Linux vendors, etc.
I'll take an open source compiler that is installed everywhere over a commercial one that is only on a handful of machines.
Re:Simply ludicrous (Score:3, Informative)
Old news... (Score:5, Informative)
Re:Where is all this going (Score:1, Informative)
Have you ever looked at a P4 mother board? The real estate for the fan is easily double what it is on an Athlon motherboard.
Nothing to see here, move along (Score:1, Informative)
http://www.intel.com/cd/software/products/asmo-na
2) Only a moron would buy Intel's compiler to develop for AMD processors (even if they didn't know about 1))
3) From TFPDF: "ISVs are forced to choose between Intel's compilers, which degrade the
performance of their software when operated with AMD microprocessors,"
How exactly are ISVs forced to choose "between" Intel's compilers? Those developing on AMD should NOT use Intel's compilers in the first place since Intel does not support that CPU.
(BTW, ISVs are not forced - they are enticed - to choose Intel's compilers. Can they prove Intel forces ISVs to buy their compilers?)
5) From TFPDF: "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."
Unbeknownst to them, the fucking product page does not even list AMD processors as supported. What do they expect? "Blistering" performance?
Re:The Limit of Lawsuits (Score:4, Informative)
That's patently not true
Fair enough. A single mis-predicted jump will flush the entire pipeline.
Thanks for the correction.
Re:The Limit of Lawsuits (Score:2, Informative)
"Accelerate Windows* Applications
Develop high-performance software for desktops, servers, handheld devices and mobile phones that is optimized for Intel® architecture using Intel® Compilers for Windows*."
Note is says Intel architecture, which AMD processors are compliant with, not Intel processors. Therefore, I would reasonably expect that claim to be substantiated in the resulting code.
A workaround for one of the compiler's tricks (Score:5, Informative)
This is not the only anti-Athlon trick in the compiler, but it's an easy one to verify and understand.
From: iccOut (iccout2004@yahoo.com)
Subject: sleazy intel compiler trick (SOURCE ATTACHED)
View: Complete Thread (4 articles)
Original Format
Newsgroups: comp.arch
Date: 2004-02-09 14:38:40 PST
As part of my study of Operating Systems and embedded systems, one of
the things I've been looking at is compilers. I'm interested in
analyzing how different compilers optimize code for different
platforms.As part of this comparison, I was looking at the Intel
Compiler and how itoptimizes code.The Intel Compilers have a free
evaluation download from here:
http://www.intel.com/products/software/index.htm?i id=Corporate+Header_prod_softwr&#compilers [intel.com]
One of the things that the version 8.0 of the Intel compilerincluded
was an "Intel-specific" flag.According to the documentation,binaries
compiled with this flag would only run on Intel processors andwould
include Intel-specific optimizations to make them run faster. The
documentation was unfortunatelylacking in explaining what these
optimizations were, so I decided to do some investigating.
First I wanted to pick a primarily CPU-bound test to run, so I chose
SPEC CPU2000.The test system was a P4 3.2G Extreme Edition with1 gig
of ram running WIndows XP Pro. First I compiled and ran spec with the
"generic x86 flag" (-QxW),which compiles code to run on any x86
processor.After running the generic version, I recompiled and ran
spec with the "Intel-specific flag" (-QxN) to see what kind of
difference that would make.For most benchmarks, there was not very
much change, but for 181.mcf, there was a win of almost 22% !
Curious as to what sort of optimizations the compiler was doing to
allow the Intel-specific version to run 22% faster,I tried running
the same binary on my friend's computer.His computer, the second test
machine, was an AMD FX51, also with 1 gig of ram, running Windows XP
Pro. First I ran the "generic x86" binaries on theFX51, and then
tried to run the "Intel-only" binaries. The Intel-specific ones
printed out an error message saying that the processor was not
supported and exited.This wasn't very helpful, was it true that only
Intel processors could take advantage of this performance boost?
I started mucking around with a dissassembly of the Intel-specific
binary and found one particular call (proc_init_N) that appeared to be
performing this check. As far as I can tell, this call is supposed to
verify that the CPU supports SSE and SSE2 and it checks the CPUID to
ensure that its an Intel processor. I wrote a quick utility which I
call iccOut, to go through a binary that has been compiled with this
Intel-only flag and remove that check.
Once I ran the binary that was compiled with the Intel-specific flag
(-QxN) through iccOut, it was able to run on the FX51. Much to my
surprise, it ran fine and did not miscompare. On top of that, it got
the same 22% performance boost that I saw on the Pentium4 with an
actual Intel processor. This is very interesting to me, since it
appears that in fact no Intel-specific optimization has been done if
the AMD processor is also capable to taking advantage of these same
optimizations. If I'm missing something, I'd love for someone to point
it out for me. From the way it looks right now, it appears that Intel
is simply "cheating" to make their processors look better against
competitor's processors.
Links:
Intel Compiler:http://www.intel.com/products/software/in dex.htm?iid=Corporate+H
Metrowerks sold their x86 compiler assets. (Score:3, Informative)
http://www.metrowerks.com/MW/Develop/Desktop/defa
"Metrowerks recently sold its Intel x86 compiler and debugger technology to a third party. As a result, Metrowerks will no longer create and sell products that include this technology. Metrowerks will offer support for these products by hosting on-line discussions on newsgroups and on our web site.
This sale does not affect the right to use CodeWarrior or create x86 code by customers currently licensed to use CodeWarrior x86 compilers."
Re:Regulators Raid Intel Offices (Score:4, Informative)
One might call the dropping of the price of MS's stock from above $120 to $20 within weeks of the judgment a negative result.
And when would this dramatic stock price drop have happened? The data I can find doesn't show this at all. Stock price history [morningstar.com]. Be sure to consider the effect of stock splits too.
Comment removed (Score:2, Informative)
Re:Simply ludicrous (Score:5, Informative)
They don't target AMD though... (Score:3, Informative)
At least they're being fair about it. *eye roll*
Re:Simple Solution: WRITE YOUR OWN COMPILER!!! (Score:5, Informative)
Re:Simple Solution: WRITE YOUR OWN COMPILER!!! (Score:4, Informative)
Re:Why? A Better Question.... (Score:3, Informative)
Because "anyone" would know that certain code paths are going to be faster on both AMD and Intel processors than others. An SSE2 optimized code path is going to be faster on both chips than an x87 code path. Yes the chips are different but both do better with certain kinds of code.
Why would this be the case? Because AMD tried to make their SSE2 support as fast as possible so that it could run the same code as an intel compiler just as fast! AMD is not in a position to expect everyone to optimize their code for the underdog's processors. They have to make sure the code that exists runs fast.
Yes, they are going to be differences in the most optimal sequence of instructions depending on the microarchitecture of the chips. This does not mean that the optimal code path for Intel is automatically sub-optimal for AMD. Why would you assume that?
You don't see any fault because you aren't comprehending the situation. The CPUID instruction returns, among other things, a bit field detailing all of the instruction set extensions supported by the chip. AMD processors have supported SSE2 for years, and have this bit set. These instructions are quite fast on AMD processors, because they have to be. The Intel compiler produces code that uses SSE2, and other instructions if the compiler doesn't support it. However to determine which code path to use, the Intel-generated code uses the processor name returned by CPUID rather than the feature bits. It checks for "GeniuneIntel" or "AuthenticAMD", and uses either the fast code path or the slow one.
It has nothing to do with compatability, and everything to do with detecting and crippling a competitor's chip.
AMD and GCC (Score:4, Informative)
Re:Send that to AMD's legal team! (Score:4, Informative)
It would be one thing if the compiler always spit out binaries that ran only on Intel CPUs and errored out when attempting to run on anything else, but it's churning out a multi-path binary that sets up all sorts of unnecessary hurdles for execution on non-Intel CPUs and sends all CPUs not returning a "genuine Intel" ID string down that path. There are already standard methods of determining whether a given CPU is SSE2 instruction compatible, and it's not done by checking the CPU manufacturer. The fig leaf of "ensuring compatibility on unknown hardware" just doesn't cover their actions here.
Another EXCELLENT reason to use cross compilers (Score:3, Informative)
He did it to show that even theoretical attacks, which have never been seen in the wild, can be effectively mitigated out of existence.
Never forget that the Open Source development community have been working towards providing more secure environments [bastille-linux.org], whether you make use what is available is up to you.
maow.