Slashdot Mirror
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.""
In other news...
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?
More
Because a compiler just spits out machine instructions, it's a trivial task to compare the instructions from one code path to another.
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.
I thought someone said there was going to be free beer!
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.
The submission is old news. Anyone who read the earlier AMD antitrust documentation knew about this claim. It's among the things Intel has done to drive AMD to dirt.
However, what's news, is that EU antitrust investigators raided Intel and some OEMs today...
http://theinquirer.net/?article=24554
They probably were hunting for some documents related to alleged antitrust violations - nice free additional ammo for AMD and their case, methinks...
That's not what AMD is saying. RTFA. AMD is saying that their chip will run the same binary code produced for the Intel chip. They are saying that Intel deliberately creates substandard code when it detects and AMD chip.
Jack Valenti and Orrin Hatch will be first up against the wall when the revolution comes.
The filing actually has a ton more complaints than just what the poster mentioned. Here is the relevant section:
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.
-- thalakan
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.
Yes, and no.
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).
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
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.
This won't be hard to prove. Pretty much anyone who wants fast 32Bit code uses the Intel Compilers, even on AMD. However it is a known fact that you need to force the compiler to use optimizations if an Intel Processor is not detected.
Not for the last few years, in fact AMDs x64 line runs a lot cooler than any Intel processor I've seen.
http://www.acm.org/classics/sep95/
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.
Take a look at this page for an example. Also, try here.
Maybe you can do what this guy did, if you haven't already seen it.
No;
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.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
If you're too lazy to read the postings here shows such evidence.
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".
We do. The company I work for makes a very comprehensive graphics application, designed to deal with images from film and higher (thing 4k images at float point).
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.
- sarcasm is just one more service we offer -
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
Winged Power Photography
If the GNU people can make a compiler for every fricking chip on the planet on their own dime, surely AMD can write a good C / C++ compiler for their chips.
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.
"My opinions are my own, and I've got *lots* of them!"
A single jump instruction, and you have to flush the entire pipeline!
:-)
That's patently not true
Fair enough. A single mis-predicted jump will flush the entire pipeline.
Thanks for the correction.
Javascript + Nintendo DSi = DSiCade
For about a year, I've been patching my Intel Compiler compiled code because of this issue. I have to give credit to a poster on the comp.arch newsgroup for an explaination of ONE of the issues, and a workaround.
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
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
A good investigation can be found at http://www.swallowtail.org/naughty-intel.html
That's just not feasible. Unlike Intel, AMD isn't huge and they don't have a massive software team. However, they aren't stupid and have funded and helped develop compilers. In particular gcc received a lot of help from AMD, especially in developing the AMD64 target.
The enemies of Democracy are
Nope. Metrowerks was spun off with, and belongs to, Freescale. Which you would know, had you done something so simple as go to their home page and read the words: "Metrowerks - A Freescale Semiconductor Company".
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
AMD is currently working with the Free Software communinity (including working with both SUSE and Red Hat) to improve GCC support on its platforms. At present, there are no direct contributions from AMD to the Free Software Tools, but that will change in the future.
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.
If a job's not worth doing, it's not worth doing right.