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.""
... attribute to malice that which can be fully explained by incompetence.
- some great thinker I'm misquoting
The Astroturf_Alert is accepting nominations.
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?
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.
Wow... that's a great example, and you should gather as much evidence of it as you can, especially Intel's responses, and send it to AMD's legal team.
MOD PARENT UP
$8.95/mo web hosting
IF AMD can find instances in the compiler of "if Intel then...else if AMD then..." they'll have a case. But this may just be an instance of Intel knowing best how to optimize for Intel processors.
...software. Something like this would never be implemented in an open source compiler. With open source, you know exactly what you get... with closed, you get what the owners want you to get, which will help their bottom line.
Meh.
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.
Awww... A competitor's compiler is not optimized for our architecture. Cry me a river.
There is a subtle difference between "not optimised" and "goes out of it's way to slow it down".
A subtle, possibly criminal difference.
in the compiler case, I don't think it is something they can legitimately complain about. Intel and AMD processors are actually different, and it appears that Intel has done some extremely aggressive optimization for their own processors. In particular, the pipeline length for the Intel processors are much longer, so instructions need to be scheduled differently to be optimal.
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
I love Mondays. On a Monday, anything is possible.
Seriously, if you've still got the documentation, send that to AMD's legal team.
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.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Intel is under no right to make their compiler work efficiently on AMD chips. They can't be expected to spend time on what compiler flags produce the best code on every AMD chip out there. So having it output generic code is the best bet. Of course, if that code is intentionally buggy, that's another issue.
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.
Part of AMD's claims is outrageous. Why would AMD expect its competitor, Intel, to write software that supports AMD's own products? We would not expect IBM to modify AIX or any other IBM software package to run on SPARC, which is a poorly designed processor.
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.
Javascript + Nintendo DSi = DSiCade
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)Quidquid latine dictum sit, altum videtur
Intel makes a compiler and a debugging aid for their chips. AMD should make one for theirs. It sucks to go to AMD's web page and they don't have nearly the developer resources that Intel has. 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.
This is my sig.
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.
"Those who are too smart to engage in politics are punished by being governed by those who are dumber" -- Plato
What a Maroon!
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.
Just another "Cubible(sic) Joe" 2 17 3061
Isn't Prescott 32 stages nowadays? Silly Intel. Gotta have the bigger pipeline, huh?
;-)
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!
Javascript + Nintendo DSi = DSiCade
It's very simple. If I were a programmer buying Intel compilers (I mostly do administrator work) would I have been reasonably led astray by their advertising to think that what Intel was selling was an X86 compiler that didn't play favorites? There's an enormous class action waiting out there for programmers who thought they were getting something (an honest x86 compiler) but werent and had to deal with user complaints from customers who suffered. There's a similar end user class action just waiting for an enterprising lawyer to set up.
End users and programmers have no interest in supporting Intel processor dominance but were tricked into that by Intel's underhanded dealing.
It's one thing if you don't go out of your way to support an entirely different architecture that you don't make yourself, but it's entirely different to intentionally cripple your program when it finds out it's running on your competitor's hardware that's fully compatible with your own.
Define "force the compiler". Is it a command line switch, or something else?
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.
Yeah...the fab they've been opening up apparently have nothing to do with capacity. Moron. AMD has more then enough capacity. The lawsuit is in an effort to make *use* of that capacity. Apple would have been a drop in thte bucket to AMD, but Apple needs chipsets as well, which is *one* of the reasons they chose Intel. Do some actual research before spewing FUD, okay?
who depend on sites like Slashdot to cull the most newsworthy items from the multitude of sites, mail lists, and other sources, it is news.
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.
You don't get it.
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.
The mods are on crack, how you got modded up is beyond me.
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.
"If you are going through hell, keep going." - Winston Churchill
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.)
Well, one this is for sure - it will be fun to watch those lawyers explain compiler theory to the jury!
Why doesn't AMD release their *own* compiler? On a AMD tuned compiler I bet the performance isn't so great for on an Intel processor.
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.
I don't see any problem at all with this if it is indeed for all non-intel processors. Targeting a competitor directly by slowing things down is a bad thing, but putting in the simplest default fallback for any other processors than the one you are trying to optimize for seems like a very reasonable way to go. To put it this way; Intel makes a compiler optimized for their products, and they throw in a simple fallback to supply simple code that should work on any basic x86 compatible. If it can be demonstrated that the intent of this is to damage AMD it is a bad thing, but it seems more likely that Intel simply does not care about the performance of the compiler on any other implementation (and seeing how they by no means have a monopoly on compilers there is nothing wrong with that).
Here's a script to auto gen those options for gcc:
http://www.pixelbeat.org/scripts/gcccpuopt
The larger pipelines are also in anticipation of most compilers performing inlining and loop unrolling, in which case, many asm instructions will occur in sequence without any branching.
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.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
How involved in gcc development has AMD been? I'd love for them to contribute heavily toward making gcc-produced code fly on AMD64 cpus.
It would be great if gcc were the reference compiler for AMD64.
It's not so much a matter of making an optimized compiler, it's a matter of a compiler specifically crippling itself if "genuineintel" isn't detected.
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.
"Nothing strengthens authority so much as silence." - Charles de Gaulle
AMD does work on developing GCC, to an extent. I mean, how do you think x86-64 support came about? Through magic? Even if they didn't necessarily assign the whole compiler division to turn out an AMD-branded compiler (which, after all, would run contrary to the point, and they don't have Intel-like resources in this regard anyway), they've provided plenty of technical help in an effort to make x86-64 the success it is. The compiler support was available well before the chips came out.
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.
Because then nobody would use their compiler at all. They wanted to subtly punish buyers of AMD CPUs, not drive away compiler customers.
If a job's not worth doing, it's not worth doing right.
On any non-Intel processors,
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.
Why does everyone expect Intel to have an *obligation* to write optimizations in THEIR COMPILER for a COMPETITOR'S chip? And they don't specifically check for AMD and write bogus code if so -- quite the opposite. They check if they're running on Intel, and if so they put in faster code that's specifically designed for Intel processors. I'm not seeing the problem here. This lawsuit should be thrown out. This is like suing OpenOffice for having full support of their own file format, but "DISCRIMINATING" against Microsoft Word by not supporting it as well.
So is the issue with the compiler at compile time or at runtime? In other words, is it:
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.
I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
according to this guy, 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.
grey wolf
LET FORTRAN DIE!
If the comments and links I've read are correct, the check is like this:
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.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
Someone else may feel free to chime in, but it does seem suspicious or, at the least, a conflict of interest that the fines go to the authorities in Europe, while they go to the competitors (treble damages) in the US?
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 said no... but I missed and it came out yes.
Regardless of who has better chips and regardless of what capitalism is all about. Having a healthy competition is one thing. However, Intel taking the roll of the punisher when AMD is involved is another. You want more sales? Then as usual, try to outdo AMD by benchmarks. What this boils down to is its the customer's choice of who they wish to go with, not Intel's. When Intel begins to start forcing/punishing the user to go with their products, then someone needs to step in because the customer should never lose the right to choose.