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.""
Never (Score:2, Insightful)
- some great thinker I'm misquoting
Wouldn't We Notice It? (Score:4, Insightful)
If that statement is true, wouldn't there be programs all over that ran fine on Intel but crashed on AMD? Maybe there are and I haven't noticed? Maybe not many people use Intel compilers?
Instruction timing??? (Score:2, Insightful)
I thought that instruction timings, number of pipelines etc are different on amd, so code that's best for intel won't be best for amd.
Send that to AMD's legal team! (Score:3, Insightful)
MOD PARENT UP
Let me play Devil's Advocate on this.... (Score:2, Insightful)
Another EXCELLENT reason to use open source.. (Score:5, Insightful)
Re:Wouldn't We Notice It? (Score:3, Insightful)
It wouldn't be optimized for Athlon anyway (Score:1, Insightful)
The code path that is super-optimized for Pentium 4 chips wouldn't be the best code for an Athlon chip anyway. For example, if the instructions are arranged to minimize pipeline stalls on a Pentium 4 (which I assume they would be if the code is "fully optimized"), that would not be the most optimal arrangement for running on an Athlon, which has a different internal design.
So even if there was only one code path, it would be optimized more for Pentiums than for Athlons. One can't expect Intel to put lots of effort into optimizing for their competitor's products!
However, that doesn't explain why there would be a separate code path for Athlons. They could just produce the one code path, which would work OK but not optimally for Athlons.
Re:Use GNU Compilers! (Score:2, Insightful)
There is a subtle difference between "not optimised" and "goes out of it's way to slow it down".
A subtle, possibly criminal difference.
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.
I agree with most of AMD's complaint, but... (Score:2, Insightful)
That Intel hasn't done the same aggressive optimization for AMD processors can't be too surprising.
Intel has hired some of the best compiler writers in the world (they had to, for the Itanium project) and have created a great compiler. Nothing is stopping AMD from doing the same thing.
On the other hand, the "retroactive rebates" and innumerable other marketing techniques described in the article seem to be absolutely beyond the pale of antitrust laws. It is rampant abuse of the worst order. The pressures that they apply on various manufacturers and distributors are completely shameless, and are well documented. If the laws of this country are enforced (a big if!) then AMD has them dead to rights.
Thad Beier
Hammerhead Productions
Re:It's true--and they know about it (Score:3, Insightful)
That's a clear instance of them using their monopoly power to damage AMD's reputation with a developer (you).
This *exactly* the sort of evidence they will be using to build their case.
Re:Write their own compiler then (Score:2, Insightful)
That said, binaries compiled on Intel run just fine on AMDs. Showing that those optimizations at least work on AMD, and AMD's version of IA32 is stable and good.
Write your own compiler? Hell, AMD could dump a few mil on the FSF, and get GCC banged into shape. Someone on the GCC teams should approach them...
Get some more features built into the new GCC 3.x optimization framework. It'd benefit not only AMD support, but everyone else as well, as the back-end would have more optimizations added/tweaked.
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.
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)Write Your Own Damn Compiler, AMD! (Score:3, Insightful)
not the same (Score:4, Insightful)
There's a difference between not supporting hardware and using your position to intentionally tank someone else's product. They have to go out of their way to make code execute crappy on AMD. If they were being chip-agnostic and it just didn't run on AMD, that would be different.
Re:The Limit of Lawsuits (Score:2, Insightful)
Re:Send that to AMD's legal team! (Score:2, Insightful)
Re:Another EXCELLENT reason to use open source.. (Score:5, Insightful)
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 (Score:1, Insightful)
Intel is producing a compiler that optimizes for Intel chips. Yup, memcpy() went south on a non-Intel chip/architecture. And, you found a work-around.
Now, how is Intel to know the alignment behaviour of OTHER (proprietary) architectures. Yup, read the docs, etc. Same as you would.
But, they are producing an optimizing compiler for the INTEL chip. Never claimed it optimized for AMD, or anything else. If you don't use the the correct target processor, I seriously think that would be your problem.
Intel does NOT have a monopoly on processors (and, if it is proven in court that they do, THIS ANALYSIS WILL CHANGE). They certainly don't have a monopoly on compilers.
I haven't seen ANY evidence that the ICC goes out of its way to crash other processors, but it CERTAINLY doesn't produce good code for them.
Be happy with Visual C++, it generates good objects across a variety of Intel and AMD processors. Note that Intels claim has been that IF you use an Intel chip, ICC will provide a performance improvement.
I think I am going to short AMD -- something is seriously amiss there...
Ratboy.
Re:The Limit of Lawsuits (Score:5, Insightful)
Indeed. Only Crays and DSPs used to have pipelines that long. A single jump instruction, and you have to flush the entire pipeline! In super-computing and DSP, you almost never see a jump, so there's no concern. But in Intel's zeal to win the clock rate wars, they maxed out the pipeline to an absolutely ungodly length. And a 2.2 GHz AMD64 *still* outperforms a 3.2 GHz Pentium!
Seems that Intel's P4 design backfired on them. Of course, that may be due to Intel's belief that the Itanium would take the market by storm. They did learn from their iAPX 432 chip by at least producing a method for emulating x86, but they failed to take into account how deeply entrenched the x86 performance crowd was. Now AMD64 is eating Intel's lunch! (Oops!)
And as a person who's designed a simple (can't do too much in 10 weeks) 2-issue out of order machine, let me tell you, that's fun stuff. Really makes you appreciate how insanely complex real processors are. And don't even get me started on their branch prediction...
I hear you. Trying to cram a reasonable chip into an FPGA can be quite a challenge. If MicroCode hadn't been invented, it might not be possible to fit one in so few transistors. At least we can finally stop the CISC vs. RISC debate. The MicroCode designs provide CISC instructions on top of RISC cores just to confuse the heck out of both sides. Next up, writing a VI clone in LISP!
Re:The Limit of Lawsuits (Score:5, Insightful)
End users and programmers have no interest in supporting Intel processor dominance but were tricked into that by Intel's underhanded dealing.
Re:It's true--and they know about it (Score:5, Insightful)
Re:Simply ludicrous (Score:3, Insightful)
Re:The Limit of Lawsuits (Score:4, Insightful)
As others have pointed out, Intel allegedly went out of their way to secretly hobble code on AMD CPUs. Normally, there would be nothing wrong with pulling a dirty trick like this.
However, this is an *anti trust* case. If you are hold a monopoly position in a market, you are prohibited from taking advantage of that position in various ways, and that may very well include this particular dirty trick.
Re:Simply ludicrous (Score:2, Insightful)
For the rest of us... (Score:5, Insightful)
Congratulations. You're on the gcc mailing list and the rest of us must now bow before your mad news reading skills. You are truly one to behold.
Re:Intel Fortran Compiler works fine for me on AMD (Score:3, Insightful)
The Intel compiler (inlcuding the fortran one) is generating code that looks something like:
if (processor == real intel processor && processor supports SSE/MMX/SSE2/SSE3)
{
Use super optimized code path using MMX/SSE/SSE2/SSE3
}
else
{
Use slower, stupid code path.
}
Instead of
if (processor supports MMX/SSE/SSE2/SSE3)
{
Use super optimized code path using MMX/SSE/SSE2/SSE3
}
else
{
Use slower, stupid code path.
}
They do this *very specfically* to make sure that even though AMD supports the instructions it wants to execute, it won't use the fast path.
This is not some accidental design where it was easier to do this. Intel's marketing folks basically told the compiler folks to do this, or so the story goes.
If you were to patch the check at the beginning of your programs so that it returned true on AMD cpus as well, everything still works fine (in *all* cases), *and* it will run faster on AMD cpus.
Try it. If you look at the posts above, someone has posted the variable you need to reset that it is checking.
Re:Send that to AMD's legal team! (Score:3, Insightful)
The original code path can run on any x86 chip! Why was an alternate code path even created? Now, if the check said "if thiscpu_mmx_enabled == true, then use fast mmx path, else use slow non-mmx path" then it'd be a legitimate optimization with built in compatibility.
But the compiler doesn't care whether a chip is capable or not, it just cares that it's Intel or not.
Re:The Limit of Lawsuits (Score:4, Insightful)
Part of AMD's claims is outrageous. Why would AMD expect its competitor, Intel, to write software that supports AMD's own products?
Well it supports the x86 architecture. It doesn't have to support special features of AMD, but it should not purposely run different code (than it would on an intel proc) to crash the system. That's pushing the limit on anti-competitive, next thing you know ford is selling fuel that runs great in their cars but can tell if it's in a toyota and decides to spontaneously combust in the tank then.
Oh yeah, on the SPARC note, you need to take a computer arch class if you think that they are poorly designed.. if anything the x86 arch is the biggest hack of all.
On a related note, is there any way by which the authors of the GNU compiler collection (GCC) would limit the range of x86 instructions generated by GCC compilers....
Once again you have obviously never taken any classes regarding the subject. So you want to force all cisc processors to become risc by changing gcc to only support simple instructions? (which are not necessarily faster, just look at the cycles some complex operations take then try to create something in asm that does the same in the same amount of cycles using only simple instructions). Have you forgotten that GCC is not the only compiler in the world? Did you not RTFA?! It's about the intel compiler for goodness sakes! If GCC was crippled as you suggest, no one would use it, end of story.
Oh and less transistors on a chip? Brilliant. I assume you don't want faster computers or something. All the advanced branch prediction, out of order code execution etc that makes todays processors process that much faster than previous ones is thanks to the extra transistors.
If you want to talk about how computer architecture should change, take at least one class in it. It is really interesting (believe it or not) and you would learn a lot about what has been tried and done and why certain choices were made.
Re:I agree with most of AMD's complaint, but... (Score:1, Insightful)
Defrauding consumers is general tolerated in America, even much more blatent efforts. What surprises me is that Thad Beier is willing to ADVOCATE fraud, and help disguise it lies and spin, under his own name publically.
Aren't you worried that in the future peole might google on your name and find this post ?
Re:Send that to AMD's legal team! (Score:5, Insightful)
If I were Intel, I would respond with the product description of the Intel compiler, as found here http://www.intel.com/cd/software/products/asmo-na
The product is clearly labeled as a high performance compiler for Intel CPUs. The grandparent used the wrong tool for the job which required a generic compiler.
Re:It's true--and they know about it (Score:5, Insightful)
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.)
*grabs popcorn* (Score:3, Insightful)
Why? A Better Question.... (Score:2, Insightful)
This is a case where a compiler can go "if it is a 'processor-type-a' use these instructions otherwise use something else". I don't see any fault here. Intel has created a compiler that uses their chip's optimal settings. An efficient instruction set of instructions for a P4 will not be the same for an Athlon anyway due to internals of both chips being different. Why would anyone believe otherwise?
Unless Intel is pushing their compiler as the end all be all compiler for AMD there is nothing goofy going on. It is just like using GCC and C code with a bunch of carefully chosen extensions. Expecting these extensions and assembly modifications to work the same on every x86 chip is a pipedream.
Re:It's true--and they know about it (Score:2, Insightful)
Re:Simply ludicrous (Score:3, Insightful)
http://www.pixelbeat.org/scripts/gcccpuopt [pixelbeat.org]
Re:It wouldn't be optimized for Athlon anyway (Score:5, Insightful)
Re: Loop Unrolling (Score:2, Insightful)
Re:Simply ludicrous (Score:5, Insightful)
yes, ICC generates faster code even on AMD-CPU's than GCC (for example) does. But that's not the point AMD is making. AMD claims that ICC detects whether the CPU is an AMD-CPU. If it is, it generates slower executables, even though there's no real technical reason to do so. It does so merely to put AMD at a disadvantage. Yes, the code might still be faster than GCC-generated code (you could say that it tells quite a bit about GCC as well....), but it's still crippled when compared to Intel-code.
Speaking of gcc... (Score:1, Insightful)
It would be great if gcc were the reference compiler for AMD64.
Re:Simply ludicrous (Score:4, Insightful)
What they SHOULD be doing is checking the supported features of the chip and enabling the extensions dynamically as the features are available or not.
To just say "oh, it's not Intel, therefore we'll just use a standard x86 instruction set, no matter what the chip reports it's actually capable of" is the kind of BS that gets companies in hot water. If they want to prove how good their CPU is, then they should be trying to do that as fairly as possible. Playing compiler tricks will only fool people in the shortterm and will catch up with them...
N.
Re:Work on GCC! (Score:1, Insightful)
I think the main problem is the goal of GCC isn't necessarily to be the fastest compiler out there, but rather the most portable and correct one. Hence why they eschew machine-specific optimizations for more generic ones whenever possible. The Intel compiler is more in the mold of traditional vendor-supplied compilers, which try to get as much performance out of their hardware as possible, at whatever the cost in terms of microoptimizations and even correctness. If AMD tried to submit a bunch of AMD-specific optimizations for GCC, they'd probably be shot down.
Re:Apple MP3's? since when? (Score:3, Insightful)
Re:Send that to AMD's legal team! (Score:3, Insightful)
Re:Send that to AMD's legal team! (Score:3, Insightful)
Re:Intel has NO NEED to ensure compatibility. (Score:3, Insightful)
Because then nobody would use their compiler at all. They wanted to subtly punish buyers of AMD CPUs, not drive away compiler customers.
Re:It's true--and they know about it (Score:3, Insightful)
I think this is a key fact.
It isn't that ICC generates crummy code for AMD cpus, it generates good code for Intel cpus and crummy code for all others.
AMD would have a much stronger case if they were able to demonstrate that ICC compiled code actively detected AMD cpus and took the slowpath.
Instead, it is reasonable for Intel to argue that the slowpath is a fallback option that is designed for maximum compatibility at the expense of performance. Since they take the same slowpath on ALL unrecognized CPUs (cyrix, transmeta, ???) some, or all, of which may not have been part of Intel's test process -- maximum compatibility is a very reasonable design goal, better than simply refusing to run which is another option.
The end result is the same, but the supporting reasoning behind such a move is likely to prevail in a court of law where, in a dispute like this, motivation makes all the difference.
Am I the only one who doesn't fault Intel here? (Score:2, Insightful)
Re:Simply ludicrous (Score:3, Insightful)
a. compile on an AMD CPU, compiler detects that it runs on an AMD and generates a binary that runs slower on both AMD and Intel CPUs, or...
b. compile anywhere, generated binary checks whether it runs on Intel or AMD and runs slower on AMD?
First one is easy to check for - compile the same source on each of the 2 architectures and compare binaries. If not the same, QED. The second one is sneakier and needs debug/tracing.
Re:Let's Clarify this WHOLE DEBATE (Score:3, Insightful)
according to this guy [swallowtail.org], it is in fact a boolean test of Intel/non-Intel. correct me if i'm wrong, but AMD is the only competing company to provide an SE2 solution, so i would go as far as to say this is singling them out. the Fortran compiler 7.1 executes a mov $0x1, 0x0 in the case of non-Intel chips, regardless of SSE support. compiler 8.0+ executes SSE instructions in the case of existing SSE support, optimized SSE2 instructions on Intel chips supporting it, and crippled SSE support on non-Intel ships.
if AMD is the only other provider of an SSE2-supporting chip, this could easily be construed as singling-out.
Re:Wow (Score:2, Insightful)
If (GenuineIntel)
{ supported_extentions = Check_CPU_Capabilities();
Run_optimised_code(supported_extentions);
}
else
{ Run_generic_x86_code(); }
So on any non-Intel CPU, the generic x86 code path will be chosen, but on Intel it will use the best supported (MMX/SSE/etc) code path.
So no specific test for AMD, but at the same time 'willful ignorance' of the x86 extensions supported by non-Intel CPUs. Definately not playing nice, and something that Intel compiler customers certainly are in their right to complain about. But I kind of doubt that it is illegal for Intel to do so, unless there is supporting evidence of Intel going beyond generic x86 in sabotaging AMD CPUs (e.g. generic x86 code especially crafted to run bad on AMD CPUs, smoking gun internal emails etc).
Being an AMD only customer for the last 5 years, I hope AMD has facts to back their claim.
Re:Regulators Raid Intel Offices (Score:3, Insightful)
As far as I know, the European laws are designed to protect the Public. Therefor, the "public" - through the form of its government, receives the damages. Correct me if I'm wrong here though.
I have no idea why you guys bash AMD (Score:2, Insightful)