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.""
Not being a compiler or chip guru, how does one work out that a compiler favors a specific chip? I can understand that it might be easy to detect code that looks for a specific chip, but then how do they determine that the resultant code is being optimized based on that detection?
I think I speak for nearly every person as naive as I was five minutes ago when I say, "holy fucking shit!"
If true - and that's a big 'if' - I know a lot a lot of people who will soon stop using Intel compilers. This could lead to some significant changes across a large portion of the gaming industry, for starters.
--Ryv
It does this if it's compiling the code targeting AMD or if it's compiling the code and an AMD chip is running the compiler?
If the latter... wow.
Between this and exactly how brazen it looks like their contract abuse was, you'd think Intel could have learned to be less baldfaced about this. Even Microsoft hasn't been this unsubtle since the 80s.
If this is true, Intel deserves to be hung out to dry.
I'm glad AMD is pursuing this action against Intel just because I like rooting for underdogs, but this lends them the moral high ground they might have been seen to be lacking by some in the tech media.
No gods, no demons, and no masters. Secular Humanism!
I am huge AMD fan myself, but this has me a little worried. If they can really prove their claims great for AMD, but if not I fear they risk looking like SCO and becoming the brunt of many jokes.
Madre de Dios! Es El Pollo Diablo! -- Captain Blondebeard
I noticed this problem back in January of 2004, with Intel C++ 8.0, and went through heck over nine months with Intel's customer support to get it fixed until I eventually had to abandon their compiler.
... If the performance of memcpy/memset only are improved for Pentium III will that satisfy you?"
On any non-Intel processors, it specifically included an alternate code path for "memcpy" that actually used "rep movsb" to copy one byte at a time, instead of (for example) "rep movsd" to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I'd ever seen, and was around 4X slower than even a typical naive assembly memcpy:
push ecx
shr ecx, 2
rep movsd
pop ecx
and ecx, 3
rep movsb
They responded with completely ridiculous answers, such as:
"Our 8.0 memcpy was indeed optimized for a Pentium(r)4 Processor,when we reworked this routine we used the simplest, most robust, and straightforward implementation for older processors so that we didn't need the extra code to check for alignment, length, overlap, and other conditions."
BS. I went and added the following line to the beginning of my source code:
extern "C" int __intel_cpu_indicator;
then I added:
__intel_cpu_indicator = -512;
to the "main" function.
This forced Intel C++ to use the "Pentium 4" memcpy regardless of which processor in in the machine. It turns out that their special "Pentium 4" memcpy which I tested thoroughly in all kinds of situations, and it worked perfectly fine on an AMD Athlon and a Pentium III. I pointed this out to them.
I received the following response:
"The fast mempcy is over 2000 lines of hand coded assembly, with lots of special cases where different code paths are chosen based on relative alignment of the source and destination.
I answered "No," saying that I needed support for AMD processors as well. I also gave them a copy of my own memcpy routine that was 50% faster than theirs--and just used MMX. They closed the support issue and did nothing to resolve it.
I switched back to Visual C++.
It's hard for thee to kick against the pricks.
Well, I don't think they would make such a claim without at least some sort of evidence. And we all know that Intel is a corporation that doesn't like to play nice with the other kids. During my senior year of undergrad my computer architecture professor consistently refered to Intel as "the evil empire", so who knows. I'd like to see AMD present some hard evidence though.
Hero of Allacrost, a FOSS RPG for *NIX/*BSD/OS X/Win
Why is it a surprise that an Intel compiler will optimize code to an Intel chip. If they intentionally bloated the machine code for AMD processors, then that is wrong...but is it wrong for Intel to not learn the inner workings of an AMD chip and not optimize its compiler for that chip??
Lets see, if one looks at almost ANY software license what does one see? "This may not be suitable for blah blah blah blah we disclaimed any liability for damages.". Ever since http://www.constructionweblinks.com/Resources/Indu stry_Reports__Newsletters/Sept_18_2000/defective_s oftware.htm">
M.A. Mortenson Co., Inc. v. Timberline Software Corp. the courts have held that if you accept the license, it's not their fault. Even if they knowingly produce a faulty product.
Is it dirty pool - sure is. Is it illegal? That remains to be seen. AMD most certainly has a firm ground to stand on when it comes to antitrust and Intel.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
Not to mention the fact that AMD still benchmarks very favorably in games and other CPU-intensive applications, so the slowdown can't be huge.
However, I doubt AMD would claim this if it weren't true. They still have a business to run, unlike SCO, and don't want to damage their reputation.
I suspect that the "crash" part is more conjecture than fact, since the unoptimized code paths might be assumed to be lower quality in many ways. Or perhaps AMD found a single instance of a crash that occurs in one of the unoptimized code paths and even if Intel didn't mean for it to be there, they're still on the hook for that path in the first place.
I have a feeling AMD has been working on this lawsuit for several years, so it will be interesting when they do finally submit the evidence to the court.
The global economy is a great thing until you feel it locally.
imagine that, the company isn't taking time to waste R&D for a product they don't make.
It makes a great deal of scense to me.
You know the in's and out's of your own product. You can optimize code for your product, why should they have to optimize code for someone else's product? Maybe that company should be writing their own compilers?
Are people really that lazy? Why do the companies that _MAKE_ money get fucked over? because the little companies that only went into business to get a CHUCK of that money, are mad they're not getting enough... Fuck 'em.
It's like putting a fence around your house. your protect your assests.
Its more likely that intel understands their processors inside and out and know how to fully optimize compiling for them. The reason it changes things for AMD is probably due to not knowing what would happen if they used the same optimized code. It doesnt really make sense for a company to spend time optimizing the compiler to work with other processors when they sell their own.
I know how this can happen (and it has nothing to do with being evil).
The engineers get the specs for the next version of the compiler. They also get a slew of bug reports from the last version. They have a short amount of time to impliment the new specs, and fix the bugs.
The bug reports will be something like, "on AMD processors when doing a memcopy with optimization xyz turned on, the processors mispredicts half the time. This makes it very slow."
The engineer in that case, turns the optimization off for that generated code, thereby 'fixing' the bug (but not really). It happens all the time.
It's not a nefarious plot, it's the same time crunch issue that every software engineer has to deal with.
Since when did operating systems become a religion?
Actually the current Intel compiler (The one AMD is complaining about) is optimized for Intel P4 processors.
It either compiles for a P4 or for x86. Since AMD falls into the category of "other" it uses a different memcpy which takes a lot longer. (roughly 2x - 4x as long).
This enables the "other" code to run in basically any 286+ x86 processor but makes P4 code fast.
It is not anti-competitive so much as not suited for the task of compiling not P4 targeted code.
In both home and work purchasing decisions, I've been refusing to buy Intel machines for years now because I felt Intel processors were overpriced and was hearing rumours of anticompetitive practices like this. It has gotten easier to justify this prejudice as mobo support improved and AMD increasingly kicked Intel's ass over the last five years or so.
6. Audible Alarm (not shown)
-from a Cuisinart product owner's manual.
Personally, I think this is a bit of a grey area. Obviously, it seems wrong that Intel should be crippling software, but at the same time, they aren't making anyone use that compiler in the way they are making people not sell AMD products (maybe I'm wrong, I didn't read that enourmous legal document). Ultimately, this whole thing is secondary to the monopolistic discount allegations, anyway, so it would be nothing more than icing if it's true. It does make for a nice "they're big meanies!" finger-pointing fest, though, huh?
I'd rather be cycling.
You paid 1/3 less than $300 for a full color unit, with 15hour battery life, tv-out, and a 20gig drive? nice :D
Would this effect 3D graphics rendering or movie encoding/decoding benchmarks? It seems those are the two areas Intel chips still beat AMD chips.
First of all, the Intel compiler only creates processor routing code if so selected by the user. Otherwise, you can target any level of architecture just like any other compiler and no processor forking occurs. Second, when you do use processor routing, it simply forks off to code optimized for the processor you select if it detects that specific processor. For example, if you optimize for a P4, two (at least) branches are created: one optimized for the P4 and one for anything else. The anything else branch isn't "degraded" it's just unavoidably not as optimized. My understanding is that an AMD and P3 would BOTH see the less optimized code if you selected P4 code to be generated.
Why are you surprised? AMD has the higher IPC/MIPS design.
Though in this case the solution is simple. Don't buy Intel, don't use ICC. Usually on my P4 I can trick GCC [-fno-regmove comes up] to getting similar performance as ICC v8.
Even then, ICC has good schedulers but performs fewer higher level optimizations. So GCC is usually better in that respect.
Tom
Someday, I'll have a real sig.
q[With open source, you know exactly what you get.]q
Which, in this case, is really crappy performance.
There's really only one reason to use Intel's compiler -- for performance. It's well known that Intel's compiler generates code that vastly outperforms everything else for the same platform (namely Microsoft Visual C++ 6/7 and gcc -- everyone else (Watcomm, Borland) has long since been relegated to "also ran" status).
We're talking about a rather significant performance difference too -- 20% or more typically. Even more if you compare to gcc (x86 may be one of the most optimized target platforms for gcc/g++, but it's still got a long, long way to go comparatively; even to MSVC).
Intel also has one of the better C++ compliance records as I recall, although MSVC++ 7.0 pretty much eliminated that gap (gcc was far better than MSVC 6, they're roughly equal now), so that's another reason to use them.
But really it's all about the performance. If you have a product targeted for x86 and performance is one of your top criteria, then you'd be foolish to not consider using Intel's compiler for your builds. The reason not everyone does so is because it's expensive and the UI isn't as good as MSVC, particularly for debugging.
All of that said, the allegations are still damning. Yes, Intel has the right to tune the compiler for their CPUs. But if the alternate paths are coded stupidly or intentionally bad-case (worst case is not required) then they could be found to be engaging in anti-competitive behavior. Even if those code paths affect Intel processors as well -- it just has to affect only old Intel processors (hello upgrade!).
Additionally, you might be able to make a (weak) argument that using the "heavily optimized" path only on your own CPUs after having been informed that it works just fine on other CPUs is also anti-competitive. As stated, it's a very weak argument though, since if you do so you'd then have to test any changes you made in that particular heavily optimized code path on the other systems -- which you don't have as much knowledge on.
Of course, the question is why hasn't AMD come out with their own compiler? They should be dedicating resources in this direction instead of (or as well as) litigating Intel. If they don't want to build their own compiler, that's fine -- simply dedicate some time to helping gcc improve its low level compilation performance. I'd be surprised if the gcc x86 team wouldn't welcome any real support of that nature (and by that I mean an employee assigned to actually writing code, or at least a very direct line to AMD engineers that could help an existing gcc coder).
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.
Intel doesn't come close to a monopoly in the compiler market, so I fail to see what this has to do with the antitrust suit.
That's because you're trivializing the issue. Intel has a chip monopoly their compiler has a huge influence - even if it isn't used in production by the majority of their customers. Purposely reducing the efficiency for AMD chips is a great example of anti-competition, which is what monopoly laws are all about.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Come on, AMD... If you do need to do your own compiler work, optimize GCC! The whole idea is to make code run fast on your chips, right? And think of the tremendous goodwill you'd build up, especially around here.
Yes but, they knew enough to block W3C's validator from their site:
w .slashdot.org%2F
http://validator.w3.org/check?uri=http%3A%2F%2Fww
"A mind is a terrible thing to taste."
Uhm, excuse me, but isn't the compiler assembly what is running?
And therefore you can inspect it using a debugger? Or by comparison with the output of an uncompromised compiler that does nearly but not exactly the same compilation methods used by the suspected one?
I think Thompson's point was that while inspecting the source code of the compiler will not reveal if the compiler is compromised, if you have the compiler output, you can still detect it.
This means you can certainly compromise any software if you don't have access to the source code, and if you have the source code, it could be harder. But if you have the output, you can certainly detect the compromise.
One way would be to run the same program through a compiler that is made by someone else which presumably does not use the same method of compromise and compare the output. It would be hard, but no harder I assume than detecting whether copyrighted code is included in some other software.
In fact, this is what Thompson actually said:
"You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of SOURCE-LEVEL [Emphasis added. RSH] verification or scrutiny will protect you from using untrusted code."
He did also say that the lower-level this sort of thing is done on, the harder it is to detect - it would be nearly impossible on the micro-code level. Which seems to support AMD's contention that the Intel modifications could be sabotage, not just conservatism in compiling for non-Intel processors.
In general, of course, while Thompson's point may be valid, it mostly applies to companies or hackers who may have a motivation - and more importantly, a reputation - to do something like this. It would be pointless for someone like GNU to do it. It would get out and it would damage their reputation.
While Thompson said no code other than that written by yourself can be trusted, I hardly think he requires everyone in the world to write their own assemblers, compilers, operating systems and applications (and design their own CPUs to avoid micro-code tampering). Given that, I'd say that open source is still far more likely to be trustworthy than closed-source.
Which renders the entire discussion here moot.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
In that case, how come when the compiler is tricked into thinking it's running an Intel processor when really it's AMD, the performance increases?
This is obviously nothing to do with the advantages of the processor. The only possible answer is that Intel is deliberately generating poor code for AMD's processors, in order to hamper their competitor. This is inexecusable.
But there is another company howling for their blood and ready to replace Intel with a more ethical approach.
:P
AMD will probbaly be sued into oblivion
It seems to me that the obvious long-term solution for AMD is to write their own compiler.
And I've often thought the same of Novell - I always believed that one of the primary reasons NetWare foundered was because Novell never wrote their own compiler for the operating system. It was damned near impossible to write an NLM in the old days - you had to get a copy of Dr Watcom, and then do a bunch of undocumented wizardry just to get it to produce a simple "Hello World" output.
Anyway, for those of you computer establishments that lack your own in-house compiler, there's this cell phone company, called Motorola, which has pretty much ditched their chip fab subdivision, but which retains this little subsidiary called "Metrowerks", a subsidiary which doesn't seem to integrate very well with their forward-looking core strategy of providing the means to share Paris Hilton pr0n over hand-held cellular devices...
Hi akaimbatman, we meet again ;)!
;-P
:-/
(rolls eyes) You again.
Frankly I am not into the compiler world (I'm no C/Fortran programmer), so I didn't expect that programs compiled with the Intel compiler would even try to work on an AMD CPU.
That would be a perfectly acceptable answer, and the one that AMD would like. However, the Intel compiler is not just producing highly optimized code and leaving it at that. Highly optimized code would work fine on an AMD CPU, partly because AMD has a technology cross-licensing contract with Intel. (Which means that Intel could produce AMD64 CPUs if they wanted!)
The core of the issue is that the code generated by the Intel compiler uses the slowest code path available if the CPU is an AMD. That's a potential Anti-trust violation, and smacks of desperation on Intel's part. I've always been overall happy with Intel's handling of their monopoly, but Moore is no longer at the helm and I fear that Intel may be slipping.
Javascript + Nintendo DSi = DSiCade
If they put a warning in the EULA for the compiler about it not being efficient in non-Intel processors, then Intel would definitely be in the clear, but if they sold their product as simply a vanilla x86 compiler, then they've got shit to be responsible for.
Learn something new.
I don't know the anser but what about some of the weider ones out there:
IDT Winchip, Cyrix 486/133 and other oddball cpus?
My point is that I don't believe Intel intentionally broke the compiler for AMD, I think they took the approach of supporting their hardware fully, while using the _most compatible_ paths for everyone else. If that is what they did then AMD's argument is worthless. That doesn't change the end result, but it does insulate Intel from any legal wrongdoing.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
There isn't anything really poorly designed about the SPARC, which isn't to say it doesn't have some things nobody would put in a new CPU. For example it is one of only 2 commercial RISC CPUs with register windows (the other being the ill-fated AMD 29k), so I doubt anyone would do that again. It has (optional) branch delay slots, which were a win for a few years, but on OOO CPUs you can get the same gain without the pain. It also has a MULSTEP instruction, which is pretty much a waste when you have the transistor budget for a real multiplier.
All of those can be forgiven as either actually a good idea in the late 80s, or at least not a known to be bad idea. Even the much maligned register stack was a pretty effective cache with way fewer transistors for a while there.
SPARC hasn't suffered because it was a crap design, it has suffered because it doesn't have the same volumes the x86 does, so Intel putting $0.02 per CPU back into R&D gets it a bigger R&D budget then Sun pouring $1000 per CPU back into R&D. Disclaimer: I made those numbers up. Totally invented.
I resent that. I optimize my inner loops (and the outer loops, and even the startup initialization data is cache aligned...) and develop games and I use MS VC6 for Windows and GCC for Linux/*BSD* exclusively.
What sort of silly person would expect an INTEL compiler to generate decent AMD code anyways? While I didn't expect intentional sabotage, I'm not entirely surprised either. It's not like it's in Intel's best interest to spend millions on creating an optimizing AMD compiler.
I'm interested in who purchased it, especially considering the upcoming transition of Macs to Intel-based systems.
Cyric Zndovzny at your service.
And when would this dramatic stock price drop have happened?
There was a stock split that took the price from $120 to $60 overnight. The drop to and stagnation at the $25 range for the past few years is not the result of the DOJ ruling, but reflect the fundamentals of Microsoft's stagnating business. Indeed, if the DOJ outcome had any effect, it would be to inflate the MSFT stock price because it demonstrated that the DOJ was impotent to stop Microsoft from further abusing its monopoly position.
This seems to be it. I haven't tested it yet.
I used to work at Intel and when I was there I know they compiled the MSVCRT file in Windows to work better on Intel chips than on AMD chips.
I think the statement was, "If you can't optimize it for Intel, then at least cripple it for AMD", or something to that effect.
I'm sure they do the same thing with their compiler and other things.
Now ask yourself again: do you believe that it's PURE COINCIDENCE that Intel's compiler produces slow code for its competitor's processors?
Do you believe that it is pure coincidence that Intel's compiler produces fast code for their processor?
when you see the word 'Linux', drink!
Sure. But what other mainstream i386 CPUs are out there that isn't AMD? VIA? Your Verilog implementation of the instruction set on your home PC? If that's the case, then both Cyrix and you should help AMD because they're obviously hating VIA and you too. If that's not the case, then AMD is the only major competitor to Intel, and the statement "looks for non-Intel" is EQUIVALENT to "looks for AMD."
The fact is, it is SUFFICIENT to only test for the presence of SSE/SSE2/SSE3 instruction set. Anything more, like "GENU" "INEI" "NTEL", is absolutely unnecessary. Afterall, why would Intel care if the code fails on non-Intel CPUs if ICC is only meant for Intel CPUs (which it isn't)? On the other hand, if the ICC is designed for other CPUs, then Intel obviously would know (afterall, Intel IS licensing the SSE/SSE2/SSE3 instruction set to AMD) the capabilities of said CPUs, in which case they should enable SSE/SSE2/SSE3 for CPUs capable of the instructions. Last I heard, there weren't any problems with AMD's SSE/SSE2/SSE3 implementation. Therefore, the bottom line is this boils down to a Catch22 situation and Intel should know better than to pull such cheap tricks. If Intel is going to assume that any CPU that implements the i386 instruction set does this without major problems, then why would they not assume the same with SSE/SSE2/SSE3?
Furthermore, if you actually read some of the user posts (and their links http://www.swallowtail.org/naughty-intel.html), you would have realized that ICC deliberately produces segfault code when the execution of the code doesn't find an Intel CPU. According to the article, this is with the -xK flag. That is, it produces ONLY SSE code, and NO fallback to i386 code. Yes, that means this code will fail on the original Pentium. However, in this case, Pentium will still try to execute the SSE code (and subsequently craps out), while AMD CPUs will not (and automatically segfaults). This kinda throws the "and then does 'i386' code path, which is less optimal" argument out the window....