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.""
Simply ludicrous (Score:5, Funny)
That is an outragous claim! No company would stoop so low. Why, that would be like claiming that Microsoft configured its servers to give broken HTML to browsers other than Internet Explorer. That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. That would be like saying that Adobe publishes pdfs that b0rk XPDF.
Anybody can see that this claim is ludicrous and that things like this just don't happen. (but I hope I'm not giving anybody any ideas.)
Type your currency conversion into a free form text box
Re:Simply ludicrous (Score:5, Funny)
Re:Simply ludicrous (Score:5, Funny)
Re:Simply ludicrous (Score:5, Interesting)
http://validator.w3.org/check?uri=http%3A%2F%2Fww
Re:Simply ludicrous (Score:5, Funny)
http://validator.w3.org/check?uri=http%3A%2F%2Fsl
Regulators Raid Intel Offices (Score:5, Informative)
They'll probably be convicted and then buy the regulators like MS so they only get a slap on the wrist.
On that note, was there *anything* negative that came of the Microsoft monopoly ruling?
Re:Regulators Raid Intel Offices (Score:5, Funny)
Well for starters, Microsoft is still here.
Re:Regulators Raid Intel Offices (Score:3, Interesting)
AMD will probbaly be sued into oblivion
Re:Regulators Raid Intel Offices (Score:4, Funny)
Re:Regulators Raid Intel Offices (Score:4, Informative)
One might call the dropping of the price of MS's stock from above $120 to $20 within weeks of the judgment a negative result.
And when would this dramatic stock price drop have happened? The data I can find doesn't show this at all. Stock price history [morningstar.com]. Be sure to consider the effect of stock splits too.
Re:Simply ludicrous (Score:5, Interesting)
Re:Simply ludicrous (Score:5, Funny)
>> without at least some sort of evidence
We agree.
- darl
Re:Simply ludicrous (Score:5, Informative)
Re:Simply ludicrous (Score:3, Insightful)
Re:Simply ludicrous (Score:5, Informative)
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.
Re:Simply ludicrous (Score:5, Informative)
If you're too lazy to read the postings here shows such evidence. [slashdot.org]
It's an example showing the poor assembly-language code when it detects an AMD chip. And notice in that posting that the complier is perfectly capabile of producing efficient AMD code as well. It's sad but funny that the workaround to produce fast code for the AMD chip is to add the string "__intel_cpu_indicator=-512".
Re:Simple Solution: WRITE YOUR OWN COMPILER!!! (Score:5, Informative)
AMD and GCC (Score:4, Informative)
Re:Simple Solution: WRITE YOUR OWN COMPILER!!! (Score:4, Informative)
Apple MP3's? since when? (Score:3)
Can you find an instance of Apple ever giving MP3's to play in the iPod?
Re:Simply ludicrous (Score:3, Funny)
(that should have been followed by the obligatory:)
oh wait...
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.
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:3, Informative)
That's patently not true [wikipedia.org]
Re:The Limit of Lawsuits (Score:4, Informative)
That's patently not true
Fair enough. A single mis-predicted jump will flush the entire pipeline.
Thanks for the correction.
Re:The Limit of Lawsuits (Score:5, Funny)
Hello, did someone say "Vi clone in LISP?"Ya mean, like that?
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:3)
How about because Intel's compiler customers would expect Intel to do so?
It's hardly the same as refusing to allow your OS to run on another company's processors. If you don't want your compiler to support AMD, engineer it that way and say so to your customers. Building in stealth methods of sabotaging performance on the CPU is hardly the way to go (if in fact that is what Intel did without good engineering re
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: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: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:The Limit of Lawsuits (Score:5, Interesting)
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.
How can this be done? (Score:4, Interesting)
Re:How can this be done? (Score:5, Informative)
For example, you write some code that would typically use SSE2 regisers when compiled, then you compile the code for each processor, and check to see if it used SSE2 registers on each, or if it ouput slower "emulation" style instructions on the AMD.
Re:How can this be done? (Score:5, Interesting)
The company I work for submitted a few reports on this a few months ago, as I am sure did many others. I am very pleased to see them following up on it.
Re:How can this be done? (Score:4, Interesting)
My company writes some code that depends on SSE2 instructions. We bought one AMD (64-bit) machine, but code was slower on Athlon64 3200 than on P4 3000 (under WinXP, not on some 64-bit system). We heavily depend on every tact, so I would really like to know how to trick Intel's compiler to believe that AMD is P4.
Re:How can this be done? (Score:5, Informative)
Re:How can this be done? (Score:4, Informative)
Also, the lawsuit claims that Intel's compiler wont use x86 ISA extensions such as SSE2 even when they're available on AMD processors. There is a reason we have these kinds of ISA extensions, and it is becaue performance is much much better when you use them.
Re:How can this be done? (Score:3, Informative)
This assumption is wrong
see here [bell-labs.com] and here [bell-labs.com]
if it wasn't for licensing hiccups the plan9 c compiler would be OpenBSD's default by now
"I am sorry for the strong minded way in which I am approaching this,
but I am very dissapointed [sic] that after years of requesting that the
plan9 c compiler become free so that we can start extending it and
working with it... t
Re:How can this be done? (Score:5, Informative)
Re:How can this be done? (Score:4, Informative)
CmdrTaco == automated script (Score:4, Funny)
$gotaco = "submit";
$spellcheck = "no";
$dupecheck = "definitelynot";
} else {
// I got nothing. *shrugs*
}
Re:CmdrTaco == automated script (Score:5, Funny)
Patch for your script (Score:3, Funny)
*** 5,7 ****
} else {
-
}
--- 5,7 ---
} else {
+
}
************
Where is all this going (Score:4, Interesting)
Re:Where is all this going (Score:5, Funny)
Well, they do require quite a lot of cooling, don't they?
Re:Where is all this going (Score:4, Informative)
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?
Re:Wouldn't We Notice It? (Score:4, Interesting)
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.
Re:Wouldn't We Notice It? (Score:3, Insightful)
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)Re:Compiler + host platform + target platform comb (Score:4, Informative)
There are a lot of companies who take performance very very seriously. We are just one of them.
The problem here has nothing to do with crashing, it has to do with the problem that companies that have chosen the Intel compiler for it's excellent performance suddenly find themselves producing software that is much slower on AMD systems than it needs to be.
The options are to switch to a different compiler and take the performance hit that comes from that (which can be quite significant) or put pressure on Intel to stop trying to 'innovate' using underhanded tactics.
Since we can hack around the problem for now by tricking the compiler into thinking our AMD is a Intel, I choose to try pressuring Intel before we try switching.
Re:Wouldn't We Notice It? (Score:3, Informative)
The story is light on details and doesn't say if the compiler is generating code optmized for the P4 or if it's code supposedly optimized for the AMD or if it was one of those "blended" things. If it's optimized for P4, then I can easily see how intel's instruction ordering can be beneficial for them, and slow the AMD.
Things like pipeline length and differing branch predictors can cause wi
Work on GCC! (Score:5, Interesting)
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.
It's true--and they know about it (Score:5, Interesting)
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++.
Send that to AMD's legal team! (Score:3, Insightful)
MOD PARENT UP
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:Send that to AMD's legal team! (Score:4, Informative)
It would be one thing if the compiler always spit out binaries that ran only on Intel CPUs and errored out when attempting to run on anything else, but it's churning out a multi-path binary that sets up all sorts of unnecessary hurdles for execution on non-Intel CPUs and sends all CPUs not returning a "genuine Intel" ID string down that path. There are already standard methods of determining whether a given CPU is SSE2 instruction compatible, and it's not done by checking the CPU manufacturer. The fig leaf of "ensuring compatibility on unknown hardware" just doesn't cover their actions here.
Re:Send that to AMD's legal team! (Score:3, Informative)
Re:It's true--and they know about it (Score:5, Funny)
And when a Microsoft product is the lesser of two evils, you know for sure that there's something fishy going on.
Re:It's true--and they know about it (Score:5, Funny)
push parent, @AMDsubpoena_list
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:It's true--and they know about it (Score:4, Interesting)
Re:It's true--and they know about it (Score:4, Interesting)
A workaround for one of the compiler's tricks (Score:5, Informative)
This is not the only anti-Athlon trick in the compiler, but it's an easy one to verify and understand.
From: iccOut (iccout2004@yahoo.com)
Subject: sleazy intel compiler trick (SOURCE ATTACHED)
View: Complete Thread (4 articles)
Original Format
Newsgroups: comp.arch
Date: 2004-02-09 14:38:40 PST
As part of my study of Operating Systems and embedded systems, one of
the things I've been looking at is compilers. I'm interested in
analyzing how different compilers optimize code for different
platforms.As part of this comparison, I was looking at the Intel
Compiler and how itoptimizes code.The Intel Compilers have a free
evaluation download from here:
http://www.intel.com/products/software/index.htm?i id=Corporate+Header_prod_softwr&#compilers [intel.com]
One of the things that the version 8.0 of the Intel compilerincluded
was an "Intel-specific" flag.According to the documentation,binaries
compiled with this flag would only run on Intel processors andwould
include Intel-specific optimizations to make them run faster. The
documentation was unfortunatelylacking in explaining what these
optimizations were, so I decided to do some investigating.
First I wanted to pick a primarily CPU-bound test to run, so I chose
SPEC CPU2000.The test system was a P4 3.2G Extreme Edition with1 gig
of ram running WIndows XP Pro. First I compiled and ran spec with the
"generic x86 flag" (-QxW),which compiles code to run on any x86
processor.After running the generic version, I recompiled and ran
spec with the "Intel-specific flag" (-QxN) to see what kind of
difference that would make.For most benchmarks, there was not very
much change, but for 181.mcf, there was a win of almost 22% !
Curious as to what sort of optimizations the compiler was doing to
allow the Intel-specific version to run 22% faster,I tried running
the same binary on my friend's computer.His computer, the second test
machine, was an AMD FX51, also with 1 gig of ram, running Windows XP
Pro. First I ran the "generic x86" binaries on theFX51, and then
tried to run the "Intel-only" binaries. The Intel-specific ones
printed out an error message saying that the processor was not
supported and exited.This wasn't very helpful, was it true that only
Intel processors could take advantage of this performance boost?
I started mucking around with a dissassembly of the Intel-specific
binary and found one particular call (proc_init_N) that appeared to be
performing this check. As far as I can tell, this call is supposed to
verify that the CPU supports SSE and SSE2 and it checks the CPUID to
ensure that its an Intel processor. I wrote a quick utility which I
call iccOut, to go through a binary that has been compiled with this
Intel-only flag and remove that check.
Once I ran the binary that was compiled with the Intel-specific flag
(-QxN) through iccOut, it was able to run on the FX51. Much to my
surprise, it ran fine and did not miscompare. On top of that, it got
the same 22% performance boost that I saw on the Pentium4 with an
actual Intel processor. This is very interesting to me, since it
appears that in fact no Intel-specific optimization has been done if
the AMD processor is also capable to taking advantage of these same
optimizations. If I'm missing something, I'd love for someone to point
it out for me. From the way it looks right now, it appears that Intel
is simply "cheating" to make their processors look better against
competitor's processors.
Links:
Intel Compiler:http://www.intel.com/products/software/in dex.htm?iid=Corporate+H
Re:It's true--and they know about it (Score:5, Insightful)
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.)
I do that ... (Score:5, Funny)
profit!
This is old news, however Intel EU raid today... (Score:5, Informative)
However, what's news, is that EU antitrust investigators raided Intel and some OEMs today...
http://theinquirer.net/?article=24554 [theinquirer.net]
They probably were hunting for some documents related to alleged antitrust violations - nice free additional ammo for AMD and their case, methinks...
Is this a suprise? Does AMD have a case? (Score:3, Interesting)
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.
I think (Score:3, Funny)
Another EXCELLENT reason to use open source.. (Score:5, 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:Another EXCELLENT reason to use open source.. (Score:4, Funny)
If you mean GCC, then, yeah, I couldn't agree more with you. It's equally slow on EVERY processor
Re:Another EXCELLENT reason to use open source.. (Score:4, Informative)
Read Ken Thompson's classic paper on just that. He makes the case that it would, in fact, be not terribly difficult to hide code that does exactly what intel is being accussed of in an open source compiler, without anyone ever knowing it was there.
Re:Another EXCELLENT reason to use open source.. (Score:3, Interesting)
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 typic
Re:Another EXCELLENT reason to use open source.. (Score:3, Interesting)
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
Relevant Section (Score:5, Informative)
c. Intel's Leveraging of Its Other Product Lines to Unfairly Disadvantage
AMD in the Marketplace
122. Intel has also designed and marketed microprocessor-related products with the
goal of compromising performance for those who opt for AMD solutions, even if it requires
sacrificing its own product quality and integrity.
123. An example is Intel's compilers. Generally, independent software vendors
("ISVs") write software programs in high-level languages, such as C, C++, or Fortran. Before
these programs can be understood by a computer system, they must be translated into object
code - a machine-readable language - by a software program called a compiler. Different
companies write compilers for different operating systems (Windows, Linux, etc.) and for
different programming languages (C, C++, Fortran, etc.). Intel offers compilers for use with a
variety of different operating systems and programming languages.
124. Intel's compilers are designed to perform specialized types of optimizations that
are particularly advantageous for ISVs developing software programs that rely heavily upon
floating point or vectorized mathematical calculations. Such programs include, for example,
mathematical modeling, multimedia, and video game applications.
125. Intel has designed its compiler purposely to degrade performance when a program
is run on an AMD platform. To achieve this, Intel designed the compiler to compile code
along several alternate code paths. Some paths are executed when the program runs on an Intel
platform and others are executed when the program is operated on a computer with an AMD
microprocessor. (The choice of code path is determined when the program is started, using a
feature known as "CPUID" which identifies the computer's microprocessor.) By design, the
code paths were not created equally. If the program detects a "Genuine Intel" microprocessor,
it executes a fully optimized code path and operates with the maximum efficiency. However,
if the program detects an "Authentic AMD" microprocessor, it executes a different code path
that will degrade the program's performance or cause it to crash.
126. ISVs are forced to choose between Intel's compilers, which degrade the
performance of their software when operated with AMD microprocessors, or third-party
compilers, which do not contain Intel's particular optimizations. Sadly for AMD and its
customers, for legitimate reasons Intel's compilers appeal to certain groups of ISVs, especially
those developing software programs that rely heavily on floating point and vectorized math
calculations. Unbeknownst to them, performance of their programs is degraded when run on
an AMD microprocessor not because of design deficiencies on the part of AMD, but
deviousness on the part of Intel.
as someone who worked at a compiler company (Score:5, Interesting)
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.
Write Your Own Damn Compiler, AMD! (Score:3, Insightful)
Re:Write Your Own Damn Compiler, AMD! (Score:5, Informative)
Hey, maybe instead AMD could pay people to work on GCC. Oh, wait, they do that already. Why do you think GCC was ported so quickly to AMD64? GCC development is not, AFAIK, funded much (if at all) by the FSF anymore. It's all Apple, AMD, IBM, the various Linux vendors, etc.
I'll take an open source compiler that is installed everywhere over a commercial one that is only on a handful of machines.
The story here is the marketing practices... (Score:5, Informative)
You should really read this, it's pretty amazing. After AMD offerred HP 1 million processors to compete with Intel Retaliation, Intel upped the stakes, and HP backed down.
I for one am VERY scared about the new Apple Intel adoption. I've always been an AMD fan, but prices of late, as well as difficulting getting "approved" systems for my video editing software has made me purchase Intel for my last 2 machines. (Though I type this on a barton 3000).
I don't think Intel has been driving the innovation bus, and if you thought Microsoft was the bad guys, I have a feeling you aint seen nothin yet.
Sure are alot of people not RTFA'ing. (Score:5, Informative)
Look, the issue is this:
The compiler doesn't need to be optimized for AMD's chips. But it does need to be optimized for extensions which Intel supports. The claim is that Intel's compiler DOES NOT support their own extensions when an AMD chip is detected.
This is important because the Intel Compiler is used to compile benchmarks, enterprise level code, demonstrations, etc. Business decisions to go with one chip or another are based on the performance of the software, which was compiled from the Intel Compiler, which claims to be able to support the INTEL extensions.
By crippling the resulting code when the compiler detects an AMD CPU, Intel is essentially LYING about the performance of their processor and about the performance of the AMD processor through resulting benchmark software(s) and applications compiled with the Intel compiler.
Yes, AMD can make their own compiler, but people have to choose to use it. People who are already using the Intel compiler invested time and money into creating a development environment based on it. Switching isn't easy. If the compiler makes the AMD cpu look bad, businesses will choose to go with Intel thinking those processors gave them better bang for their buck, when the opposite might be true.
It's like having two cars that can do 125MPH, but one has been electronically locked to max out at around 85MPH, then putting them on a racetrack to determine which car is faster.
That isn't a valid comparison. And if INTEL's compiler IS purposefully generating substandard code that doesn't even support their own extensions in AMD's cpus, then benchmarks compiled with the Intel compiler are similarly invalid.
This could also mean contractual violations between AMD and INTEL since AMD licenses the enhanced extensions from INTEL.
It ISN'T about INTEL's compiler not optimizing itself for AMD specific instruction sets. It is about INTEL's compiler not optimizing itself for INTEL specific extensions on AMD CPUs, which AMD has license from INTEL and implemented in their processors.
Another way of looking at it is that AMD has licensed enhancements believing that INTEL's compiler will similarly take advantage of those enhancements. Perhaps that was in the agreement, perhaps not.
If it was the case, then AMD should be furious. They basically licensed and implemented extensions, from INTEL, into their processors that INTEL is choosing to not support. Not because it isn't compatible, the extensions were implemented to their specifications, but to be anti-competitive and deceptive in the intent of their licensing of the extensions.
A simple: if ( intel cpu) { optimized code + extensions } else-if ( amd cpu ) { standard code w/o extensions} is overly simplistic for an engineering organization like Intel and would be difficult to explain away since they are licensing their extensions.
The compiler should be checking for the existence of extensions and choosing to compile in functionality or not. Most games and graphics packages use dynamic libraries and alternate blocks of code for different extensions detected. If small, mid-sized, and large game companies can do thi
Old news... (Score:5, Informative)
Link (Score:5, Interesting)
Re:So.. wait (Score:3, Informative)
Re:It's called good business (Score:5, Informative)
Who Uses Intel's Compiler? (Score:4, Funny)
Intel probably puts in serious bucks to R&D of their compilers so their chips look the fastest. This is logical; they'd want to do what they could do enhance speed regardless of if it was hardware or software doing the speedup.
But, the operative question is, who uses the Intel compiler anyway? If I was going to compile something, and I needed really fast results, I would probably use the compiler of the hardware manufacturer- be it Intel or AMD. I'm sure AMD has a compiler tuned to exploit every possible speedup you could ask for on an AMD chip.
Further, they'd be wise (if they don't do this already) to sell/give away technical manuals for compiler writers telling them how to squeeze every little bit of extra performance out.
Commercial compiler vendors include (my estimation, please reply with additions):
* Intel
* AMD
* GCC
* Microsoft
* Watcom (still in business?)
* Borland (still doing this?)
This obviously leaves out the computer science students worldwide. But, my point is, maybe this is a wake up call to anyone using an Intel compiler that they need to switch to one of the others above (GCC especially).
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.
Re:What's surprising about this? (Score:5, Informative)
If they intentionally bloated the machine code for AMD processors, then that is wrong.
If you RTFA you'll see that AMD is charging (and numerous sources are confirming) that Intel did extra work to specifically make things slower when programs compiled with their compiler were run on an AMD. On previous poster even posted his two line partial fix for the issue that drastically improved code speed and which he gave to Intel while trying to solve this issue with the compiler. Basically it just tricked the compiler into always using the copy function for Intel processors. This was obviously malicious.
Re:Instruction timing??? (Score:5, Informative)
No, if it was using proprietary 'processor specific improvements (TM)'.
However, it is *not*.
The real answer (not Intel's answer), is Yes, because Intel's compiler (which is widely regarded as producing some of the fastest binaries out there) produces code that will only take advantage of standard processor extensions (MMX, SSE, SSE2, SSE3) on 'Genuine Intel' Processors. Regardless of whether or not AMD processors support these extensions, the code excutes in slower, emulation mode if it does not detect 'Genuine Intel'.
When you 'fake' the compiler out by having all processors return 'Genuine Intel', the compiler generates code that will utilize standard extensions that it recognizes (everything but 3DNow, and 3DNow-2), on *any* processor that supports them.
This means your athlon will run SSE code, and your athlon 64 will run SSE,SSE2, and SSE3 code.
Not to mention MMX code, which Intel even disables for non-Pentium 4 Intel processors, even though Intel processors have supported MMX since the Pentium MMX!
This kind of manipulation is clear, and the only purpose is to portray the Pentium 4 as superior, and both older Intel processors and all AMD processors would appear siginificantly faster if the compiler simply utilized whatever extensions where avaliable (on the order of 10-40% for some programs) rather than relying upon the 'Genuine Intel' flag.
Intel *is* a monopoly, and although it is not illegal for a monopoly to exist, monopolies, under current U.S. law, are not permitted to use predatory tactics, especially when going from one market to another (compilers->processors).
Re:Instruction timing??? (Score:3, Interesting)
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
Re:Oh brother (Score:3, Funny)
So that means I can cheat in business and whoever sues me is just a whining loser? Cool! Where do I sign up?
Re:Oh brother (Score:4, Interesting)
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.
Re:Before we damn Intel (Score:4, Informative)
The Compiler produces MMX, SSE, SSE2, and SSE3 optimized code, but will revert to emulation and pure integer/floating point processing if it does not detect 'Genuine Intel' and 'Pentium 4'.
It's not a question of producing optimal code in terms of processor configuration; that's a gimme. Its a question of not even permitting competitor processors to utilize standard processor extensions, including *older* intel processors that support a partial subset of those features.
Athlon 64s, by the way, support all of these, and operate perfectly, if they are tricked into reporting 'Genuine Intel'.
AMD is not asking Intel to have the compiler produce code that takes advantage of the Athlon architecture; there could be different optimizations because of the Athlon's better memory architecture, or lesser penalty for misprediction, and shorter pipeline.
No, AMD is asking that Intel not produce a compiler that intentional disables standard processor extensions for non-Pentium 4 processors.
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 thoug
Re:It wouldn't be optimized for Athlon anyway (Score:5, Insightful)