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.""
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
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 heard on Intel procs it used SSE2 and on AMD it didn't. Would create a nice "broken" compiler and a definite time difference.
Judging by the performance of using Novell Netware shares under Windows compared to a Windows server...
Milo
I click on read more and all I see is
"Nothing for you to see here. Please move along."
Dear god Im at work and have no tinfoil.
Damn the man!
... attribute to malice that which can be fully explained by incompetence.
- some great thinker I'm misquoting
The Astroturf_Alert is accepting nominations.
Thanks for the PDF warning...Sheesh!
This was listed in the anti-trust lawsuit and discussed already.
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!
if ($submission) {
$gotaco = "submit";
$spellcheck = "no";
$dupecheck = "definitelynot";
} else {
// I got nothing. *shrugs*
}
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
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 hope for AMD's sake this is true. I mean, I wish it wasn't, but AMD is risking SCO status if they are too noisy and whiny. I'm not saying they don't have a case - I'm just saying that no one wants to buy stuff from a whiner.
www.olin.edu
speaking of amd.. I'm just about to build an Athlon 64 3800 (venice core) based system. I figure the new lines are a bit to pricy. Do any of you have some experiences with that cpu worth mentioning?
- Mad, ingenous - they've both left you puzzled -
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.
...broken floating-point units and shabby multiple execution contexts. This leads to less-than-ideal optimization on well-designed architectures. AMD was advised several years back that they would need to come up with some shittier designs if they wanted to take advantage of Intel's optimizations. Shame on AMD for not making a crappier CPU.
Anyone following the GCC maining lists knows this. It has come up many times there in the past few years.
In other news...
They'll probably be convicted and then buy the regulators like MS so they only get a slap on the wrist.
On that note, was there *anything* negative that came of the Microsoft monopoly ruling?
More
That is some very devious work on Intels part. On the other hand, I can see from an Intel perspective how if they write the compiler, they can make it do as they please. AMD needs to come out with their own that slows down Intel chips!
Voice your opinion!
"recient"
You do mean "recent"!
In version 1.0 of my software, I always throw in some loops that just count to a million to throw in some delays. That way you can include "optimization" as a deliverable for version 2.0.
profit!
Microsoft has alleged that the gcc compiler is deliberately designed so that programs compiled with it do not run as efficiently under Windows as they do under Linux.
Mods: Do you disagree with me? Go ahead and mod me down. Meta-mods will sort it out. Good luck!
Awww... A competitor's compiler is not optimized for our architecture.
Cry me a river.
-- Dogbert
This post encoded with ROT26. If you can read it, you've violated the DMCA. Handcuffs please, sergeant.
...Microsoft alleges that Linux boxes emit gamma rays that keeps Windows boxes getting blue screens!
...Yahoo! alleges that Google Toolbar alters it's search results to include irrelevant pr0n pages!
...Cingular alleges that T-Mobile customer service reps prank call their support line during free time, resulting in shitty service!
(add your own...)
Mozilla stole tabs from NetCaptor. So what? Right?
so what if intel compiliers do that? it's the INTEL compilier. first of all, of course code compiled on the INTEL compilier is going to run fastest on intel chips b/c intel knows the inner workings of their chips better than they'd know AMDs. why spend all the money for R&D to learn AMDs chips to make a free compiler who's sole purpose in life is speed up processes on intel chips.
nobody is stopping AMD from making a free compiler that does the same thing.
STFU AMD, and ante up.
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.
The submission is old news. Anyone who read the earlier AMD antitrust documentation knew about this claim. It's among the things Intel has done to drive AMD to dirt.
However, what's news, is that EU antitrust investigators raided Intel and some OEMs today...
http://theinquirer.net/?article=24554
They probably were hunting for some documents related to alleged antitrust violations - nice free additional ammo for AMD and their case, methinks...
It is true but the article is misleading.
It does not target AMD negatively, but rather targets Intel positively. There is a huge difference.
When the compiler runs into a "genuine Intel" CPU it knows exactly how to compile the code paths to get the maximum performance. When it compiles everything else it needs to take the "safe" route and compile it as best it can (sometimes not very good at all)
Not a deliberate attack on AMD but rather a boost one would expect from a company that is providing a compiler and CPU's.
Wouldn't you expect an AMD compiler to take advantage of EVERY possible tweak it could to make code compiled for AMD processors run faster? Why call Intel the devil for doing the same thing?
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
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.
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.
Intel should get the death penalty.
if(chip == AMD)
Sleep(80);
Isn't it possible they just know their own product better and thus can create a better compiler for it?
Technology, the cause of and solution to all of life's problems.
...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.
Another example of AMD trying to win in the marketplace through whining. There is nothing preventing AMD from releasing their own compiler. Instead they are just bitching about Intel again.
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.
"The defense of freedom requires the advance of freedom" - George W Bush
If they don't like the way Intel's compiler works on their CPU's, maybe they should write their own compiler that does things better.
This post reminds me the time I caught the ferry over to Shelbyville. I needed a new heel for my shoe, so, I decided to go to Morganville, which is what they called Shelbyville in those days. So I tied an onion to my belt, which was the style at the time. Now, to take the ferry cost a nickel, and in those days, nickels had pictures of bumblebees on them. "Give me five bees for a quarter," you'd say.
Now where were we? Oh yeah - the important thing was I had an onion on my belt, which was the style at the time. They didn't have white onions because of the war. The only thing you could get was those big yellow ones...
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.
How many people uses the Intel compiler compared to other compilers? Did anyone ever suspected this before?
EvilCON - Made Famous by
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.
The combination of libstdc++, cygwin and GCC are a very slow combination due to the less-than-lightning-fast implementation of posix threads on Cygwin and the false economy of memory pools in libstdc++. It is not uncommon to see STL heavy c++ code run 4 times slower under Windows/g++ than in Linux/g++ for these reasons. If you switch to STLport (based on the original SGI STL) for Cygwin/g++ you will see a marked improvement in speed because it does not attempt to reuse nodes in maps and other STL containers.
Not clear on something:
If the programs run on AMD slow or crash as result of funny business by the Intel compiler, then wouldn't all companies and individuals using AMD processors have grounds for a class action lawsuit against Intel?
Or, more likely, wouldn't the companies that use the Intel compiler have such grounds? Because if Uber-Game is compiled with an Intel compiler, and crashes repeatidly on AMD... either the gaming house will take a hit in reputation and sales, or the QA for the gaming house will take a hit in job security and paycheck size. Either way, Intel sounds like they could be liable as such instability would (potentially) directly stem from their attempts at sabotaging AMD.
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.
When you build your application with the Intel compiler and certain command-line switches (-QxP) it may generate SSE instructions. As you might expect, it also generates a quick CPUID check prior to main() to ensure that the processor supports these instructions. This is entirely reasonable.
Unfortunately, before it checks for SSE support, it checks for the vendor string "GenuineIntel".
AMD processors return the vendor string "AuthenticAMD", so the fastpath code will be skipped regardless of the processor's support for SSE/SSE2/SSE3.
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 a chieve 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.
Wouldn't it create huge binaries if it were creating code for Intel and AMD in one executable that were actually differently optimized code?
Are filings like this normal? It has quotes like:
."
"You just gotta love a Cinderella story. . . . AMD's rapid rise
from startup to $5 billion semiconductor powerhouse is, as
Humphrey Bogart's English teacher once said, the stuff of
which dreams are made. . .
and "AMD has seized technological leadership in the microprocessor industry."
It is also very easy to read, and doesn't have the lawyer-speak i'd be expecting.
Some of the arguments are a little weak as well. Like stating that Intel's push to change the pins on the DIMM (DDR3) module was specifically to hurt and slow down AMD's release of their processors. They don't back this up though, and it seems a little contrived.
I've noticed that corporations want their employees to work and play well with others. Why won't corporations do that too? ;P
Face it, corporations would like nothing more than to see their competition disappear so that they have a monopoly. Intel will do whatever it can to stop its competitors even if it means dirty tricks and sabotage.
If "disco" means "I learn" in Latin, does "discothèque" mean "I learn technology"?
Is there some big counterfeit Processor ring I don't know about? What if the program detects a non-genuine Intel/AMD?
Is it just me, or do you hate it when people say "Is it just me..."?
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? Some instructions are simply too complex and could actually be replaced by sequences of simpler instructions, and each such sequence would actually run faster than the original, more complex instruction. A simplified subset of the x86 instructions is sufficient for compiling all computer programs.
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."
I was under the impression that the Intel compiler was pretty much useless for real world apps and was mainly used in generating bogus/inflaited SPEC scores for Intel.
I've looked around for some general benchmarks comparing:
1) GCC 4
2) Visual Studio 7
3) Intel 8
And haven't found any clear info.
Have people found the Intel compiler worth the effort in real world apps? I've heard VS and GCC have made large leaps in performance and have caught up for the most part with the Intel compiler and even surpassed it in some areas.
Of course I don't like paying for software so I'll stick with gcc -mtune=k8
-- Thou hast strayed far from the path of the Avatar.
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).
Unitarian Church: Freethinkers Congregate!
Can you find an instance of Apple ever giving MP3's to play in the iPod?
Don't blame Durga. I voted for Centauri.
The filing actually has a ton more complaints than just what the poster mentioned. Here is the relevant section:
c. Intel's Leveraging of Its Other Product Lines to Unfairly Disadvantage
AMD in the Marketplace
122. Intel has also designed and marketed microprocessor-related products with the
goal of compromising performance for those who opt for AMD solutions, even if it requires
sacrificing its own product quality and integrity.
123. An example is Intel's compilers. Generally, independent software vendors
("ISVs") write software programs in high-level languages, such as C, C++, or Fortran. Before
these programs can be understood by a computer system, they must be translated into object
code - a machine-readable language - by a software program called a compiler. Different
companies write compilers for different operating systems (Windows, Linux, etc.) and for
different programming languages (C, C++, Fortran, etc.). Intel offers compilers for use with a
variety of different operating systems and programming languages.
124. Intel's compilers are designed to perform specialized types of optimizations that
are particularly advantageous for ISVs developing software programs that rely heavily upon
floating point or vectorized mathematical calculations. Such programs include, for example,
mathematical modeling, multimedia, and video game applications.
125. Intel has designed its compiler purposely to degrade performance when a program
is run on an AMD platform. To achieve this, Intel designed the compiler to compile code
along several alternate code paths. Some paths are executed when the program runs on an Intel
platform and others are executed when the program is operated on a computer with an AMD
microprocessor. (The choice of code path is determined when the program is started, using a
feature known as "CPUID" which identifies the computer's microprocessor.) By design, the
code paths were not created equally. If the program detects a "Genuine Intel" microprocessor,
it executes a fully optimized code path and operates with the maximum efficiency. However,
if the program detects an "Authentic AMD" microprocessor, it executes a different code path
that will degrade the program's performance or cause it to crash.
126. ISVs are forced to choose between Intel's compilers, which degrade the
performance of their software when operated with AMD microprocessors, or third-party
compilers, which do not contain Intel's particular optimizations. Sadly for AMD and its
customers, for legitimate reasons Intel's compilers appeal to certain groups of ISVs, especially
those developing software programs that rely heavily on floating point and vectorized math
calculations. Unbeknownst to them, performance of their programs is degraded when run on
an AMD microprocessor not because of design deficiencies on the part of AMD, but
deviousness on the part of Intel.
Does MS VC++ use the intel compilers?
How many applications are compiled using Intel compilers? What's the reach?
Unless a lot of applications are affected is this even a real story or something to knock down once again the market leader.
... thank $DEITY for gcc.
I have worked with MANY developers on this issue, its fairly well known.
The Intel compiler does not check for feature sets, it checks for CPU type. If the CPU does not come up as GenuineIntel, it uses the slowest (but arguably the most reliable) code available -- it will not use SSE2/SSE3/3DNow/etc.
If the CPU is a GenuineIntel, it automatically uses all of the features available on that CPU to make the fastest code it can..
its really a shady thing to do -- and for reference, Intel does nearly have a monopoly on the compiler market. Just about everybody uses the Intel compiler, because on Intel machines it creates the fastest running code...
By that logic nothing malicious has ever happened ever.
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?
After a few weeks of relatively typo-free story submissions, it's nice to see the /. editors buckling down and releasing one that's just rife with typos and grammatical errors. Thanks for not letting me down; I was starting to get worried.
And so are the mods who modded you interesting.
Isn't optimizing, is compiling the slowest possible code if not ID'd as an intel cpu that someone wouldn't use even on the slowest processor. But I'm sure you and your butt licking mods already knew that and are just being twats.
...crappy Intel spellchecking on AMD CPU...took twice as long too!
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.
I don't blame Intel for putting out a compiler that tweaks code for optimal results on their chips; the P4 in particular has some properties that scream for compiler workarounds (really long pipelines, long memory latency, nasty branch misprediction costs, etc.) That's kosher.
Active sabotage, on the other hand, is just slimy. Maybe not illegal, but slimy.
Lacking <sarcasm> tags,
This type of warfare is no news to me. I'm sure many of you are already aware of such tactics used with graphics card. On several games (proudly sponsored by NVidia, Unreal Tournament 2004, Deus Ex 2, etc.) The gameplay is very laggy when run on a non-NVidia card. But on an NVidia card, even one of less processing power than the ATI cards, it will lag unbearably. I think the companies that take part in this should be brought on trial. They're trying to leverage their influence on developers to get people to switch to their products. Sounds illegal to me.
Well, you are wrong. It is a company wasting (or spending) R&D time and money to specifically hurt a competitor. This alleges that they went out of their way to not optimize for their processor, but to cripple it for a competitor. That is a huge difference, and if you don't see it then you'll probably be indicted at some point in your life.
My beliefs do not require that you agree with them.
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.
Quote: Why, that would be like claiming that Microsoft configured its servers to give broken HTML to browsers other than Internet Explorer If i rember correctly, this did happen the makers of Opera sued Microsoft because hotmail gave broken style sheets to non ie based web-browsers
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.
I don't remember all the details but in my college security class we talked about hiding things like this in a compiler in a way that can NEVER be found.
First lets make the safe assumption that the code is obfuscated. So we can't look at the compiler's executable to see if it is doing this.
The next logical place to look is the source. Well if the Intel compiler is used to compile the source then it could add anything it wants along the way. So the source is not at all a guaranteed acurate representation of the compiled code.
So the last place is the source control. But it is WAY too easy to doctor that. So there is nothing to trace back any deletions with any infallability.
Scarry.
I tried for 5 years to come up with a clever sig...only to realize that I am not clever.
One of my old bosses said he didn't like using AMD chips because some of his programs didn't run right and would crash. I thought it was b.s., but this does shed some new light on the claim. This was about a year and a half ago he told me this, and he was speaking of experiences from a few years back, so maybe he was speaking about the sub 1ghz amd cpu's.
Also, I don't think nearly as many people use Intel's compilier as Microsoft's for windows programs and GCC for open source.
If an officer ever threatens to taze you, say you have a pacemaker.
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.
Why doesn't AMD release their own compiler? They could easily fork a gcc release and open source it.
************ // I got nothing. *shrugs* // I got nothing. Well, except the millions I got paid by Andover. *lights cigar with burning stack of hundreds*
*** 5,7 ****
} else {
-
}
--- 5,7 ---
} else {
+
}
************
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.
Why dont you use AMD's compiler if your want code optimized for
AMD chips.
Oh that's right they dont have one. AMD are parastic
that live off Intel's R&D.
AMD only managed to get into x86 because IBM insisted that Intel give up the x86 design to a rival so that it could be guaranteed a second supplier for its chips. Yes they came up with EMT64 but that has just lumbered us with the legacy x86 crap that it looked like we were going to finally get to leave behind.
Due to how much better the benchmarks seemed to rate the intel processers whenever it was compiled with the intel compiler...
However the statment about "and even crash" suprises me somewhat.
Steinberg products (Cubase, Nuendo..music production software) do run better on Intel. Why noone knows but it was known to be like that.
The first several pages are a very interesting history of the AMD - Intel relationship. I learned a few things that I didn't know before like AMD was one of the original companies vying for the IBM PC crown. The lawyers for AMD draw several similarities between Intel and some of the more famous monoplies from the industrial revolution like Standard Oil and Alcoa Aluminum...kinda ballsy actually.
The compiler isn't mentioned until page 40 of a 48 page doc so this is alot bigger than just a problem with a compiler.
I am going to play devils advocate here. Not that Intel isn't guilty as sin, but it seems that reading the court document that AMD has already won a lawsuit against them of a similar nature previously. IANAL but isn't this just the same thing re-heated and re-hashed or is this Intel using a different method to unfairly inhibit AMD's ability to market thier products and AMD fighting back as it has in the past?
Discuss....
I suppose it all depends on what Intel likes to pretend their compiler is for. If it supposed to be a good general purpose compiler and the claims are true, then it isn't going too well. If it is supposed to compile only for the P4 and having the code run on anything else is a happy accident then it seems a poor choice for developers. Maybe we need to start producing Intel and AMD versions of all our x86 binaries?
I hope you patented those ideas so if any of those companies were to do something so outrageously filthy they'd owe you royalties.
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.
Remember, Intel's already been in trouble for monopolistic practices, in Japan, for example, and setttled, so you still kind of have to wonder...
Even if true, this complaint probably isn't worth much. AFAIK, Very little commercial software is prepared with the Intel compiler/libs.
I work in a computer simulation lab. We have something like 50 AMD processors running code we compiled with the Intel Fortran Compiler and it's been working great for the past two years now. We have a mixture of Athlons and Opterons. Everything is workin' great. No problems. We used to use the Portland Group's fortran compiler until we found that the Intel Fortran Compiler generates faster executables. This was the case for both 32 and 64 bit executables. Started out with Portland Group, switched to Intel...and it works great for us!
If it is their CPU, they use the special features of their product.
If it is a competing product they simply use the most reliable implementation.
Sounds quite reasonable to me, and anything less could get them in trouble.
What if they coded in an AMD feature incorrectly, and didn't happen to notice?
I work on the design team for the compiler in question. Intel releases their C++ compilers to customers knowing full well that the product is designed for the best performance out of Intel systems. The basic premise is that the Intel compiler has options for our own processors and then all other processors. Intel just writes the code for the lowest common demoninator. If you want a compiler for AMD optimized code, then I go buy something like that. Intel cannot be expected to write code for AMD processors unless AMD wants to subsidize the R&D costs. Fruthermore, AMD is suggesting that we are actively writing horrible code for their processors but I know for a fact that if we are asked to open the source code for our compiler in court it will be apparent that we have two code pathes: Intel processors and other. We have been told that AMD is developing its own compiler and they are hoping to force the court to have us turn over the compiler source code so they may integrate our optimizations into their product. AMD is nothing more than just another SCO as far as I am concerned.
This gives a new twist to (first Intel CEO) Andy Grove's motto that "only the paranoïds survive"...
The binaries compiled with Intel compilers run slower when they detect an AMD cpu which means that every AMD user is getting lower performance than they should be getting when they are running Intel binaries. That extra little bit of time that your AMD system took might mean that *you* spent a little bit longer than necessary in front of the computer as well. Is Intel compensating you for your time that they have deliberately wasted? Is Intel paying you for the extra little bit of electricity that was unnecessarily used to run the code at a deliberately slower rate?
Not new issue as many have observed. See slightly technical article at:
http://www.devx.com/amd/Article/28001
on the other hand...
the best guide to future performance is past performance...
forewarned is forearmed
and George Santayana: "He who cannot remember the past is condemed to repeat it."
In the US courts, past behavior can be used to show an indication of intent. Intel has been convicted of illegal anti-competitive behavior. Of course folks are quick to say "here they go again!"; that's only natural, and reasonable as well.
That's a nice thought but... Try reading other posts (or just reading in general) before you post. Many other educated readers who aren't so optimistically naive have shed some additional light on the issue. Plus there's been other articles posted with compelling evidence.
I thought Microsoft had to create two divisions. One to do OS's and one to do applications.
The Application division was not supposed to use OS's secrets to aid the sale of their applications.
Why should Intel be differernt?
One division to create the best hardware they can and a separate to create the best compiler they can. The separation should ensure the software division does not use hardware specific knowledge they have on the Intel chips.
If this doesn't/hasn't happened then would AMD not have cause to include the software component in its suit?
You are being MICROattacked, from various angles, in a SOFT manner.
Microsoft also got caught doing this with a particular (early) version of Windows (was it 3.1?).
And mod it up. Way up.
I mean, AMD is way out of line here.
There is neither malice, nor stupidity at work here, except on AMDs part. And AMD *has* an out -- work out their own compiler technology.
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
It's only a part of the proof. Don't forget they supoened 32 companies (or something like it) to prevent them from shredding some important papers ...
If they can prove that intel is not a fair competitor, maybe Apple will go with AMD? (Or back with IBM and their "famous" cell processor").
We do. The company I work for makes a very comprehensive graphics application, designed to deal with images from film and higher (thing 4k images at float point).
There are a lot of companies who take performance very very seriously. We are just one of them.
The problem here has nothing to do with crashing, it has to do with the problem that companies that have chosen the Intel compiler for it's excellent performance suddenly find themselves producing software that is much slower on AMD systems than it needs to be.
The options are to switch to a different compiler and take the performance hit that comes from that (which can be quite significant) or put pressure on Intel to stop trying to 'innovate' using underhanded tactics.
Since we can hack around the problem for now by tricking the compiler into thinking our AMD is a Intel, I choose to try pressuring Intel before we try switching.
- sarcasm is just one more service we offer -
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.
What AMD should do is throw some major money and development effort at GCC and make it generate really good code for AMD chips. Code that would rival what Intel do for their chips. As Stallman says, when fighting monopolies we should all help each other....
the devil is in the details. It all depends on which of the following scenarios is proven.
... //any non-intel gets i386 for 'compatibility'
... /* not intel */ { //make it slower than typical i386 code //replace movsd with movsb for no valid reason
... //make it slower than typical i386 code //replace movsd with movsb for no valid reason
... //make it crash once in a while
Scenario A (not ideal for all, but acceptable):
if(intel_p4){
optimize_for_intel_p4();
}else if(intel_p3){
optimize_for_intel_p3();
}else{
use_typical_i386_opcodes();
}
Scenario B: (doesn't specifically target AMD)
if(intel_p4){
optimize_for_intel_p4();
}else if(intel_i386){
use_typical_i386_opcodes();
}else
use_opcodes_designed_to_be_slow();
}
Scenario C:
if(intel_p4){
optimize_for_intel_p4();
}else if(amd){
use_opcodes_designed_to_be_slow();
}else{
use_typical_i386_opcodes();
}
Scenario D:
if(intel_p4){
optimize_for_intel_p4();
}else if(amd){
use_opcodes_that_crash_sometimes();
}else{
use_typical_i386_opcodes();
}
If this is scenario 'A' then it is no big deal. The other scenarios, if proven, are unacceptable. IMHO, 'D' in particular should land someone in jail.
I'll boycott intel if 'B' is proven in court only when convenient for me. But I'll boycott intel and intel-based products if 'C' or 'D' are proven in court for at least 5 years unless the management team changes substantially.
As has been pointed out by many other posters, this has been known for some time. The reality of the problem with the compiler is that while the AMD chips support a lot of the speed features in the compiler, if the compiler doesn't detect an Intel processor, it poops out and gives up.
Far more interesting are the allegations regarding Intel's actions with OEMs. They've threatened to do plenty of things to the OEMs. If the market were fair, then Dell would've been putting out AMD processors ages ago. (Of course, Dell has it's own problems - DFS and shutting down customers service forums among them.)
For me, AMD has been reliable for a long time. I refuse to buy an Intel processor because I dislike monopoly, as well as the Blue Man Group ads.
Were I a manufacturer, I would be working with Novell left and right, since the SUSE/AMD partnership led to real 64-bit support. I wish more organisations would follow behind the U.S. Dept. of Health and Human Services, and roll over to the Novell Linux environment. Then they'd have real benefit from buying AMD processors.
Linux - because it doesn't leave that Steve Ballmer aftertaste.
How many bench mark apps have been complied with this Intel Complier? Imagine all the speed gains that might appear with a recomplie with a chip neutral choice.
The compiler.
Now, Intel engineers know their own products best. They know what optimizations are safe on Intel hardware and what optimizations are not. They will not always know this for AMD products. So, AMD processors get fed a less optimized code path, that while it might not work the best, the Intel engineers can feel certain will at least work.
Wait, you think that Intel isn't providing free compilers for AMD chips AMD has some legal recourse?
Ahahaha. You are all so cute.
Intel is under no obligation to even support AMD's chips, much less provide optimizations for them. Get a fucking grip.
Hey, as a developer, I'm all for this. Now I can blame the processor when people complain about responsiveness.
Gee, I don't know what the problem is. My Linux kernel and all my utilities compile just fine on my AMD processor with gcc. What is this "Intel" you speak of?
FLR
http://www.swallowtail.org/naughty-intel.html/.
To those saying "Intel's compiler, Intel can do what it likes.", surely I am missing something here?
- Microsoft is acknowledged as a monopoly. For _OSes_, not programs.
- Microsoft also happens produce programs (IE, WMP) which hamper the competition by being free/integrated/etc..
- Everyone gets annoyed about this (antitrust in US/EU).
For this situation:
- Intel has a monopoly on the _processor_ market (correct me on this: do they?) but not on the compiler market.
- Intel also happens to produce programs (IFC, ICC, etc.) which hamper the competition (this current allegation).
- ?.
Surely everyone should also get annoyed about the Intel case? One does agree with "Intel's compiler, Intel can do what it likes.", but then why not "MS's program, MS can do what it likes."? Surely the place where the line is drawn is where the company in question is a monopoly, which both Intel (again, correct me on this) and MS are, therefore practises which would be fine otherwise, become illegal since they discourage competition and entrench the monopolist.
While this is really old news in the compiler world and is only one of many claims in the AMD complaint, Intel never said that the performance gains of using it's compiler would increase the performance of non-Intel CPUs.
The only claim that I am aware of that Intel states for it's compiler is that produces ANSI C/C++ and ISO C/C++ standards compatible software and it does do that...
All performance gains/benchmarks over other compilers or the ANSI/ISO expected output is based on Intel processor optimizations, just review the benchmarks and legal sections. So even if AMD supports the identical machine code for MMX/SSE/SSE2/etc... Intel's optimizer does not care since it is not a 'known element', so why should it allow a non-Intel proc to execute optimizations that are tested on only Intel procs? You really think Intel's compiler group is being paid to ensure that optimizations should work on AMD's chip? (Of course WE known that the code does work....;-) )
Like many people have done before and still due today, you hard-inline your critical code and you remove the optimizer from the equation. Case closed on performance...
NOW what I would like to SEE is AMD example/evidence that Intel compiler actual causes the resultant program running on AMD procs to crash. (Section/Claim: 125 in their complaint)
They should just use the AMD compiler! I mean, why complain about the Intel compiler when they could just use their own that they spent tons of money/man hours on... They could make THEIRS not work as fast on Intel processors. Clearly their's is the superior product anyways.
"I know this... this is a unix system" -- Jurrasic Park
I see a lot of posts about how wrong and bad Intel is for doing this. I agree. However it should be within their rights to create a compiler as they see fit.
How dare we depend on a private corporation to give us a good tool for use on their competitor's product?
This isn't a flame, just hear me out.
- Intel creates CPUs
- Intel, like almost every other CPU manufacturer, creates a compiler for their CPUs
- AMD creates CPUs
- AMD creates no compiler
- AMD bitches about Intel, their competition, not supporting their CPU with their compiler.
I'm really not seeing a case here.
Do we expect the Intel compiler to also support PPC and MIPS too? Are we going to sue Intel now, because they don't support 3DNow! in their compiler?
That is ridiculous.
If AMD has a case about unfair business practices regarding back room deals and contracts explicitly encouraging OEMs not to use AMD products then that's one thing, but please stick to that and don't try to make Intel look bad over this bullshit.
No other company would bend over backwards to support special optimizations for a competitor, why would anyone expect Intel to? I don't.
If AMD is upset they should write their own compiler. If you're upset as a developer you should help out with GCC, because Free Software avoids these things.
Again, I see no case here. This article was posted to rally AMD fanatics or something. I usually like AMD, but this type of thing just makes me look down on AMD and its community.
Look, the issue is this:
The compiler doesn't need to be optimized for AMD's chips. But it does need to be optimized for extensions which Intel supports. The claim is that Intel's compiler DOES NOT support their own extensions when an AMD chip is detected.
This is important because the Intel Compiler is used to compile benchmarks, enterprise level code, demonstrations, etc. Business decisions to go with one chip or another are based on the performance of the software, which was compiled from the Intel Compiler, which claims to be able to support the INTEL extensions.
By crippling the resulting code when the compiler detects an AMD CPU, Intel is essentially LYING about the performance of their processor and about the performance of the AMD processor through resulting benchmark software(s) and applications compiled with the Intel compiler.
Yes, AMD can make their own compiler, but people have to choose to use it. People who are already using the Intel compiler invested time and money into creating a development environment based on it. Switching isn't easy. If the compiler makes the AMD cpu look bad, businesses will choose to go with Intel thinking those processors gave them better bang for their buck, when the opposite might be true.
It's like having two cars that can do 125MPH, but one has been electronically locked to max out at around 85MPH, then putting them on a racetrack to determine which car is faster.
That isn't a valid comparison. And if INTEL's compiler IS purposefully generating substandard code that doesn't even support their own extensions in AMD's cpus, then benchmarks compiled with the Intel compiler are similarly invalid.
This could also mean contractual violations between AMD and INTEL since AMD licenses the enhanced extensions from INTEL.
It ISN'T about INTEL's compiler not optimizing itself for AMD specific instruction sets. It is about INTEL's compiler not optimizing itself for INTEL specific extensions on AMD CPUs, which AMD has license from INTEL and implemented in their processors.
Another way of looking at it is that AMD has licensed enhancements believing that INTEL's compiler will similarly take advantage of those enhancements. Perhaps that was in the agreement, perhaps not.
If it was the case, then AMD should be furious. They basically licensed and implemented extensions, from INTEL, into their processors that INTEL is choosing to not support. Not because it isn't compatible, the extensions were implemented to their specifications, but to be anti-competitive and deceptive in the intent of their licensing of the extensions.
A simple: if ( intel cpu) { optimized code + extensions } else-if ( amd cpu ) { standard code w/o extensions} is overly simplistic for an engineering organization like Intel and would be difficult to explain away since they are licensing their extensions.
The compiler should be checking for the existence of extensions and choosing to compile in functionality or not. Most games and graphics packages use dynamic libraries and alternate blocks of code for different extensions detected. If small, mid-sized, and large game companies can do thi
Winged Power Photography
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.
Non recognized chips get the least common denominator code since they want to make sure it works. You cant expect them to know the featureset of every random chip company...
AMD should make their CPU's software-patchable so that they report they are Genuine Intel. That is to say, the processors, as shipped from the factory, would identify themselves as AMD. But the user could get some freeware patch from the web somewhere that would put something in non-volatile memory on the chip to make it indistinguishable from Intel with respect to these compiler optimizations. AMD could totally dissociated itself from the patch simply by releasing the specs for how to do the job and letting some hackers out there do the work. They are off the hook; all they did was make a flexible piece of firmware that could be programmed by some third party to look like Intel. That third party happens to be a bunch of anonymous hobbyists. :)
The last time I was looking for a dual CPU PC for prototyping simulation code I would have loved to go for Opteron, but since there was no high performance compiler native to AMD platform, I had to go Intel.
I would have never even assumed that an Intel compiler would produce proper code on competitor's platform. Why the heck would they have done something as stupid as that? I don't understand why everybody's acting outraged as if Intel playing dirty tricks like this was unexpected.
The owls are not what they seem
For copyright or license violations, per "you may not disassemble the compiler"...
Are you kidding me?!?!?! Why the hell would the default feature of a compiler be not to do something explicitly requested in a code?!?!? I have a feeling things like this are rampant in the commercial codes because no one knows about them except the company...so they can they say their compiler runs faster than some other because they skip some operations to make it look like they are faster.
That's why I recommend we all go GNU...
Once you go GNU, it will be better for you.
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...
"My opinions are my own, and I've got *lots* of them!"
I'm not sure I understand what the big deal is about. Intel wrote their OWN compiler optimized for their OWN product. Almost every compiler made performs slightly better on one platform or another. My company uses Lahey, PGI, Pathscale, IBM, and Intel compilers and it takes a lot of testing with each compiler to find the one that works best for a given architecture.
I guess everyone's real complaint isn't that they aren't optimizing it for AMD, but that they are purposefully sabotaging it on the AMD. My opinion is that there is nothing they can fault Intel for. According to Intel's webpage for the C++ Compiler for Windows, "Achieve outstanding application performance on Intel® processors using Intel® C++ Compiler for Windows*. The Compiler plugs into industry-leading development environments for out-of-the-box productivity." And in a footnote on that same page, "Performance depends upon the specific computer systems, components and/or measurement methods used; your results will vary."
Face it, when you buy a biased technology (read IPOD), you get the compatibility and the functionality that the large company (read Apple) wants you to have. Intel is hardly the marketplace dominator in the compiler industry.
And as a flame: stop whining that AMD's are faster than Intel's when all you have to back it up is a framerate from a Carmack game. I've used both, and I can show you a handful of instances on either platform where they blow the other away. As always, use the right tool for the job. Enough said.
AMD has shown that the seperate code path executed on AMD processors runs SIGNIFICANTLY slower than simply not differentiating processors and just running the P4-optimized path.
retrorocket.o not found, launch anyway?
That could explain the performance issue. Bugs or differences between AMDs implementation of the architecture and Intel's understanding of it could explain crashes.
I am not saying AMDs claims are wrong. Perhaps they have additional evidence. But the claim that Intel degraded compiler results for AMD CPUs does not follow from the fact that the compiler generates different code for different CPUs.
1) Intel's compiler does NOT support AMD's CPUs/ eng/vtune/220001.htm
http://www.intel.com/cd/software/products/asmo-na
2) Only a moron would buy Intel's compiler to develop for AMD processors (even if they didn't know about 1))
3) From TFPDF: "ISVs are forced to choose between Intel's compilers, which degrade the
performance of their software when operated with AMD microprocessors,"
How exactly are ISVs forced to choose "between" Intel's compilers? Those developing on AMD should NOT use Intel's compilers in the first place since Intel does not support that CPU.
(BTW, ISVs are not forced - they are enticed - to choose Intel's compilers. Can they prove Intel forces ISVs to buy their compilers?)
5) From TFPDF: "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."
Unbeknownst to them, the fucking product page does not even list AMD processors as supported. What do they expect? "Blistering" performance?
...and you can disable this run-time test with the right PERL script...
"My opinions are my own, and I've got *lots* of them!"
Why? Because I think it would result in lower prices to me. While regulated monopolies (phone, electric, gas, etc.) may be necessary in order to only build a single service infrastructure, I have yet to see a market monopoly declare: Now that we've eliminated the competition, let's lower prices and improve our service!
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
That article is almost completely right on. The point is we have chosen to execute our code to check for the GI ID but no where do we purposefully degread AMD performance. AMD processors are not Intel processors and grouped into "other." It is a choice we have made to ensure compatibility with our processors. In the end, AMD suggesting that we have our compiler purposely break on their processors in a huge conspiracy theory that will be proven in court. Our customers pay us for our compiler for use on Intel systems and we specifically say in the license/contract that we won't support our compiler on anything else. Welcome to AMD, the new SCO.
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 see it also creates spelling errors, too.
Considering how superior AMD processors are to their intel counterparts, in terms of speed, power consumption, heat generation and power-verses-cost, maybe we'll see even more performance gains if AMD can get Intel to stop using bullying tactics to compensate for lack of technical superiority?
I understand AMD is licensing some Intel technology for its chips, but that doesn't detract from the reality that in many cases, AMD is producing a better product at a more reasonable price.
I stopped buying Intel CPUs several years ago. I see no reason when AMD is cheaper and faster and just as reliable (if not moreso). If AMD-centric software has been crippled, I look forward to even more performance gains once they sort this mess out.
I'm not going to claim to be particularly knowledgeable about this. But is it possible that the code the amd path uses was the original compiler code and the "geniune intel" path was added at a later date as the processors added support for sse? The original code may be quite old with only minor revisions made and they didn't bother to enable the new code for AMD paths. If by chance this is the case then it doesn't really reflect on them so poorly.
For about a year, I've been patching my Intel Compiler compiled code because of this issue. I have to give credit to a poster on the comp.arch newsgroup for an explaination of ONE of the issues, and a workaround.
This is not the only anti-Athlon trick in the compiler, but it's an easy one to verify and understand.
From: iccOut (iccout2004@yahoo.com)
Subject: sleazy intel compiler trick (SOURCE ATTACHED)
View: Complete Thread (4 articles)
Original Format
Newsgroups: comp.arch
Date: 2004-02-09 14:38:40 PST
As part of my study of Operating Systems and embedded systems, one of
the things I've been looking at is compilers. I'm interested in
analyzing how different compilers optimize code for different
platforms.As part of this comparison, I was looking at the Intel
Compiler and how itoptimizes code.The Intel Compilers have a free
evaluation download from here:
http://www.intel.com/products/software/index.htm?i id=Corporate+Header_prod_softwr&#compilers
One of the things that the version 8.0 of the Intel compilerincluded
was an "Intel-specific" flag.According to the documentation,binaries
compiled with this flag would only run on Intel processors andwould
include Intel-specific optimizations to make them run faster. The
documentation was unfortunatelylacking in explaining what these
optimizations were, so I decided to do some investigating.
First I wanted to pick a primarily CPU-bound test to run, so I chose
SPEC CPU2000.The test system was a P4 3.2G Extreme Edition with1 gig
of ram running WIndows XP Pro. First I compiled and ran spec with the
"generic x86 flag" (-QxW),which compiles code to run on any x86
processor.After running the generic version, I recompiled and ran
spec with the "Intel-specific flag" (-QxN) to see what kind of
difference that would make.For most benchmarks, there was not very
much change, but for 181.mcf, there was a win of almost 22% !
Curious as to what sort of optimizations the compiler was doing to
allow the Intel-specific version to run 22% faster,I tried running
the same binary on my friend's computer.His computer, the second test
machine, was an AMD FX51, also with 1 gig of ram, running Windows XP
Pro. First I ran the "generic x86" binaries on theFX51, and then
tried to run the "Intel-only" binaries. The Intel-specific ones
printed out an error message saying that the processor was not
supported and exited.This wasn't very helpful, was it true that only
Intel processors could take advantage of this performance boost?
I started mucking around with a dissassembly of the Intel-specific
binary and found one particular call (proc_init_N) that appeared to be
performing this check. As far as I can tell, this call is supposed to
verify that the CPU supports SSE and SSE2 and it checks the CPUID to
ensure that its an Intel processor. I wrote a quick utility which I
call iccOut, to go through a binary that has been compiled with this
Intel-only flag and remove that check.
Once I ran the binary that was compiled with the Intel-specific flag
(-QxN) through iccOut, it was able to run on the FX51. Much to my
surprise, it ran fine and did not miscompare. On top of that, it got
the same 22% performance boost that I saw on the Pentium4 with an
actual Intel processor. This is very interesting to me, since it
appears that in fact no Intel-specific optimization has been done if
the AMD processor is also capable to taking advantage of these same
optimizations. If I'm missing something, I'd love for someone to point
it out for me. From the way it looks right now, it appears that Intel
is simply "cheating" to make their processors look better against
competitor's processors.
Links:
Intel Compiler:http://www.intel.com/products/software/in dex.htm?iid=Corporate+H
I'd say if there's a specific 'if processor==AMD', in ICC/ICPC source then it implies ill intentions.
If it's simple 'if processor!=Intel', I see no wrong. It's the Intel compiler - they can do what they please w/ it.
"Create high-performance software for desktops and servers that is optimized for Intel® processors with Intel® Compilers for Linux*."
So what is the big deal? I bet that legally speaking statements like that are enough for them to avoid any liability on this issue. They are a chip company. They have a compiler to help sell chips. If you don't use Intel processors or you want your stuff to be fully optimized on AMD, then maybe you should consider using a different compiler.
The fact that Intel's compiler works better for Intel CPUs is perfectly logical.
The Intel compiler programmers have complete access to the specifications for Intel chips, as well as access to Intel hardware for testing. That makes it possible for them to introduce optimizations, and ensure that they work, for Intel CPUs. For everything else, they choose safer, more generic code. That makes sense.
Plus, it's not safe for the Intel programmers to make assumptions about the compatibility of AMD's CPUs, when we know that AMD likes to keep secrets.
Consider the alternative. Suppose Intel included the optimized code for everyone, and, due to less opportunity for testing, and lack of detailed specs, those optimizations caused AMD's CPUs to break. Then AMD would be accusing Intel of sabotaging their chips for the opposite reason, by including the optimized code instead of the generic code.
The real question to ask is, where is AMD's compiler, designed to optimize code for AMD's CPUs? After all, AMD has had over a decade to build their own compiler. But, as usual, AMD just whines when things aren't handed to them on a platter.
This is just one more example of a weaker competitor trying to get the courts to give them an advantage over a stronger competitor.
This may also be just another case of a Microsoft friend attacking a Microsoft enemy, in exchange for some unrevealed rewards. After all, Microsoft has been generating astroturf FUD against Intel for the last few years, ever since Intel starting working with Linux. The FUD is even stronger against Intel's Itanium CPU (you can see it in many of the posts for the Itanium story earlier today), due to the fact that Linux runs well on the Itanium, and Windows probably never will. Microsoft cosied up to AMD (you never see FUD articles against AMD like you do against Intel), and now AMD is attacking Intel in court, in what seems to be a rather dangerous and foolhardy move. I find that highly suspect.
The fact is that right now I trust Intel a lot more than I trust AMD. This is especially true when it comes to Linux support, because Microsoft is in a position to help AMD gain marketshare, whereas Intel is feeling held back by Windows, and wants to reduce their dependency on Microsoft. If AMD wants to change my mind on that, their going to have to come up with something better than this.
Why would you be using icc anyway if you had an AMD? Sheesh!
Metrowerks no longer produces an x86 compiler toolchain:
u lt.htm
http://www.metrowerks.com/MW/Develop/Desktop/defa
"Metrowerks recently sold its Intel x86 compiler and debugger technology to a third party. As a result, Metrowerks will no longer create and sell products that include this technology. Metrowerks will offer support for these products by hosting on-line discussions on newsgroups and on our web site.
This sale does not affect the right to use CodeWarrior or create x86 code by customers currently licensed to use CodeWarrior x86 compilers."
Cyric Zndovzny at your service.
> in the 'lead' has to help their competitor
In certain cases, yes---anti-trust law would require a company with enough market power to not abuse that power to stifle competition.
Business regulations of this sort aren't about "fairness"---they're about economic efficiency---and are important for getting the full benefits of a free market economy.
I have heard stories about Intel for years, and have even taken the trouble to test and verify some of them on my own before I got tired of the whole deal and switched to Macs a year ago. Now like a piece of bad fish, the subject has come back up with Steve Jobs announcement of Apple going to Intel. With the predatory behavior of Intel, I have to wonder how much of this was in the way of "Special Deals" by Intel and maybe a little friendly coercion. I admit I am a little biased as I would have loved to see Apple go AMD which IMHO is a much better processor company than Intel.
Devious or not, how is it in ANY way Intel's responsibility to produce a compiler that works as well for competitor platforms as Intel's, that works for competitor platforms at all.
It's not. There is no legal precedent that forces Intel to optimize their own compiler to produce great results for an AMD chip.
Is it a dirty trick that they purposelly hose code generated for non-Intel chips? Yeah. Are you suprised a big corporation plays dirty to screw the compeition? Duh.
I know AMD is the slashdot favorite, but come on. AMD is a half-ass company that can't (after decades) seem to grow itself into the type of corporation that can attract, keep, and expand on an engineering base anything close to Intel's. Bitching because you are so weak that you have to rely on a competitor's compiler and don't like the results is laughable. As usual, weak company turns to courts and fantastic claims to try and stave off Darwin.
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.
The file formats are entirely different. You'd think this would matter. It is a tech site, after all. Or are you one of those who has tried to jam a 5.25" floppy disk into your CD-ROM drive? Hey, it's a diskette, right?
Don't blame Durga. I voted for Centauri.
"That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. "
What the heck are you talking about?
I just took a read of AMD's brief. Makes me wonder if the IBM/Apple relationship was the object of similar monopolistic tactics.
There is another side to this that Intel probably will use in their defense, and which may in fact be a perfectly legitimate reason for having seperate paths. Quality Assurance.
They state that the code for certain sections the memcpy paths were optimized for the Pentium 4. Now say that you are the QA person responsible for ensuring that all of that new code creates absolutely perfect code, in all of your required situations, and say that AMD processor compilation is just a "nice to have." (how often does Ford create engine parts that work in Chrysler engines?)
So, you don't spend the millions to test this new line of optimized code on AMD chips. But you know that the old line of code (that you haven't changed) still creates perfect code, you're just going to have the AMD path use the old code.
An example. In my current position I am the QA for a java project processes monetary transactions and therefore has to work 100% each time, every time. We recently migrated away from Java1.3 (yeah, I know) to Java1.5. Now, we all know that the code works in 1.3, 1.5 AND 1.4. But we didn't have the requirement to work on 1.4, so we didn't QA it, so there's no way in hell we're going to allow it to run on 1.4. In fact, it is explicitly denied.
No responsible legal entity will open themselves up to problems down the line by blindly certifying operating parameters. This is why GCC will work on the processors the coders -know- it will work on, while a proprietary compiler (like Intel's) will work only on processors the companty -tested-.
I'm disappointed by all the ppl that screamed RTFA but didn't bother to read the article.
I've pasted below the relevant snippet from the PDF.
If you read it, you find that the Intel compiler would produce the same code independent of the compiling processor. The "special case" code happened during execution. (examples from other posts above illustrate workarounds that cause the "special case" flags to be hardcoded and never executed.
-enote
---------------------
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.
The issue is really not what cpu you are using when you are compiling but end-users may buy a product developed using the icc and find that it runs slow on the amd based system. No developer should be using the intal compiler if the finished software is to be run by users on both platforms.
Does this mean that my Counter-Strike performs worse than it could because I use an AMD64?
I would imagine that Valve uses Intel's compilers, highly regarded as they are. At least they sure as hell ain't using GCC...
that's just pathetic--
intel compilers make AMD CPUs crash?
please.
specify exactly how intel compilers do this and maybe you have a case. show an ASM code snippet at least.
the two paragraphs that bitch about CPUID are complete bullshit.
can't win? sue.
it's the american way.
https://www.accountkiller.com/removal-requested
AMD did make a performance tool called Code Analysthttp://www.amd.com/us-en/Processors/Develop WithAMD/0,,30_2252_3604,00.html. From the little I have used it, it works great. They also have some good guides on how to improve your performance. AMD isn't up to the same level as Intel with there Developer support, but they have provided some great tools and white papers to help with performance.
mnewberg.com
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.
I don't know what you're talking about. The whole point is that the generated application will use one code path when run on Intel processors and another code path when run on AMD processors. No matter whether you do your compilation on AMD or Intel.
Lots of people use ICC, but it sounds like lots of people know the workaround to make it generate decent code for both AMD and Intel, which is to make the application lie about the processor architecture at runtime.
Anyway, yes, there are definitely programs that run fine on Intel but crash on AMD and vice versa. My home computer crashes sometimes. It's AMD. My work computer crashes also. It's Intel. They crash at different times. In a system as complicated as a computer, I don't think I'll ever be able to say whether the problem is some ICC compiled game or something.
There are no trails. There are no trees out here.
When they deliberately put code into the original release of NT4 to detect if it was running on a Cyrix cpu chip and disabled the processor's cache to artificially slow it down?
So this is what Intel meant when they said secure, secure against our competitors, Trusted as in trusted to screw with our competitors. I don't understand initiative though nothing new from Intel.
Yeah, that's Intel's own compiler and they're free to do whatever they please with it. The reason is, they shouldn't have to test it for AMD processors unless AMD is willing to cover the costs of doing so. Don't get me wrong, I have an Athlon64 in my desktop, and I'm a huge AMD fan, but I'm sure there were diplomatic means of solving this issue.
I would also like to see AMD throw some money to "starving artists" who develop GCC and boost the activity there. If this makes Intel's own compiler irrelevant in the marketplace, that's fine with me. If AMD-infused GCC performs better on AMD processors, that's fine with me also.
Right now their position is not constructive. They just sit there and whine, and this never brings any glory.
Yes, Intel should spend its R&D budget developing an optimized compiler for AMD.
I'm glad we have a bunch of liberal socialists supporting AMD.
Excuse me while I go listen to Rush's "The Trees" and read some Ayn Rand.
https://www.accountkiller.com/removal-requested
Intel has just been added to my boycott list - joining Microsoft, and SCO near the top.
My next machine will be an AMD, no question about it.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Could we imagine the greatness of AMD potential as a company, especially if she manages to survive against Intel monopoly fater all? Thank you, the competition, for the bargain prices we pay for our processors and for the hardware performance we currently have! I would sponsor AMD by any possible means, as a part of the better future for industry and all customers. Personally, I do not have especially bad feelings against Intel, rather against the regulation, allowing to have what happened now. Probably, it gonna cost to Intel, and she will be the forceable sponsor of AMD R&D for a bit of time.
Integrates itself right in. Basically everything works the same, except Intel handles the compiling and linking and gives you faster code as a result. Now perhaps things have changed, but a couple years ago the ICC produced faster code for BOTH platofrms than the MS compiler, though it was even faster for Intel chips than AMD.
m l
t ml
Tom's Hardware did a test of various processors using FlaskMPEG (a program that decodes MPEG-2 and reencodes it to MPEG-4) back when the P4 was fairly new. The P4 did pathetic, worse than the P3 and Tom just panned it.
http://www.tomshardware.com/cpu/20001122/p4-03.ht
Well Intel felt something had to be screwed up, this was just the kind of thing that the P4 was supposed to rock at. So they grabbed the source and recompiled it with the ICC pugged into VC++ (the program is a VC++ program) and sent it to Tom.
http://www4.tomshardware.com/cpu/20001125/p4-06.h
Now as you can see, just the recompile (not using SSE2 optimizations) not only resulted in massive P4 speed increases, but almost doubled the speed of the Athlon. So while it certianly didn't optimize the Athlon to the same level as teh P4 (didn't do any 3dnow stuff) it certianly doesn't seem to give bad performance, at least in comparison to the MS copiler.
If you search on the SPEC CPU2000 Benchmark for "Advanced Micro Devices", you will see that AMD uses the Intel compiler. If the Intel compiler is that bad, why do they use him?
.Net 2003 using the stream and the SPEC CPU2000 on AMD Opteron and Athlon 64. The benchmark result while using Intel C++ 8.1 Compiler was a bit faster than gcc and much faster compared to the VC++ Compiler with -O3 Optimization. Same thing than using the auto vectorized option and enabling SSE2.
http://www.spec.org/cgi-bin/osgresults
I personally compared Intel C++ 8.1 Compiler, gcc (MinGW and Cygwin) and Visual Studio
May be programs could run even faster if the Intel Compiler would be fair, it's still the fastest Compiler.
I want to know the following:
1) Did Intel have access to the technical details and specifications necessary to fully optimize code for the AMD processors?
2) If not, wouldn't this be a publicity stunt just waiting to be picked up by news sites like Slashdot?
Just curious.
Hack your mind out of its sandbox.
The real question is did Intel ever CLAIM thier compiler to be compatable with other processors? Did they ever sell it is a generic compiler for all platforms or did they sell it saying "This is our compiler for our chips and it will produce rock solid fast code for our chips"
If so then those who baught it got what they paid for. What did they expect buying a compiler from a chip manufacturer?
I don't buy a BMW engine, put it in a frame I "built to thier specifications" and then complain to BMW that it does not drive like one of thier cars. That is basicaly what this complaint boils down to.
The other thing people seem to be missing here is Intel has NOT targeted AMD specificaly, they have targeted ANY processor that is not thiers. Does this make sense? YES. How else than they ensure full compliance with thier specs? Do you expect each executable to fully test every chip it is run on before executing an instruction?
The compiler is not meant to be a generic compiler, it is mean to take advantage of technology in an Intel chip. If AMD wants to compete they should write a compiler that takes advantage of thier chips.
The best they could do is offer some "certification" of the processor to allow it to report as compliant. Again though, why should they have to? Thier compiler is a product to produce optomised code to run on THIER chips, end of story.
Since at least one company has pointed out the bullshit in AMDs previous lawsuit allegations, it may be prudent to assume that this one is full of crap as well.
It's the 20th century, the century of competition by litigation.
Frankly, AMD is on thin ice as it is, being nothing but an Embrace and Extend hanger-on to the Intel CPU archetecture. They should be happy they make any money at all on their CPUs, being the remoras that they are.
Given that Intel and AMD are basically the only major players in the x86 CPU market, there seems to be no significant difference between detecting Intel vs non-Intel and detecting Intel vs AMD.
But a MUCH more basic question is why Intel's compiler designers should give a soaring adlunar coition what chip the compiler is running on. If the compiler runs well on a real Intel chip, the job's done. THERE IS NO NEED to detect non-intel chips for ANY legitimate reason. If the third-party chip is *really* Intel-compatible, the compiler will run on it; if it doesn't run, too bad for that other chip, it loses fair and square. Why spend resources to work around the competition's mistakes when you can legitimately ignore them and make the competition pay to solve their problem?
"Hey, Intel compiler support guy, your compiler craps on a MyCompatibleCPU." "Sorry, sir, it runs on all Intel chips. Not our problem, talk to MyCompatibleCPUVendor or use a real Intel chip for guaranteed compatibility."
With this context in mind, it could be persuasively argued that ANY affirmative detection of non-Intel vs Intel CPUs is a sign of a probable anticompetitive act. If the "for Intel CPU" code runs as well or better on a non-Intel chip as the "for non-Intel CPU" code, then a smoking gun is present; prepare to see a painful and embarrassing (for Intel) discovery process.
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
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.
But how many people build stuff on Amd64 with an Intel compiler ?
What's wrong with that? On my Mac, running VmWare to be able to run Win XP, so I can use CygWin in which I frequently crosscompile the latest Linux kernel optimized for AMD64 with an Intel compiler.
It's "deliberately".
Bad spelling screams out "Warning: I have a bad education, and I have nothing worthwhile to say".
Editors, this goes for you, too.
Why doesn't AMD release their *own* compiler?
AMD's Compiler would be here:
http://www.pgroup.com/
AMD worked closely with PGI while prepping the K8 core for launch to have a 64 bit compiler capable of the same auto-vectorization the icc can do.
Also, Intel does push icc as the best compiler for Windows/x86 linux (which it quite possibly is, this story aside). So they are screwing the people who buy the compiler and later find out that it intentionally sucks for 15% of the market. And AMD then gets hosed by looking appearing slower than the P4 on apps built by Intel's compiler.
I can't believe how many of you folks are missing the point of this compiler problem...
The point isn't about people who compile their own code (like us *nix folk), but the point is about people who use icc to compile binaries for wide distribution.
An example of binaries for wide distribution: MySQL has a precompiled binary that was built using icc. There are no-doubt other software packages that are compiled using icc - no doubt without a word about it in public.
Take a program like AutoCAD as a hypothetical. If AutoCAD were compiled using icc (instead of VC++), then it would scream on Intel chips yet would absolutely suck on AMD chips (if it ran at all). In this realistic case, Intel's code-path decisions are absolutely hurting the end user (and quite probably hurting AutoDesk as well).
So this can prove to be a very big problem indeed...
Ron Gage - Westland, MI
Intel does a lot more for the software community than AMD does by virtue of its market dominance. It produces compilers and chipsets to support its cpu business. AMD tries to cherrypick the most profitable aspect of Intel's business while doing as little of the unprofitable support stuff as possible.
This is an absolutely classic Hertz/Avis kind of thing. Macdonalds does enormous R&D to figure out where to put its franchises. Burger King puts its franchises across the street from Macdonalds. One can imagine Macdonalds trying to tie up potential Burger King leases before acquiring a site for one of its stores.
I don't see that Intel is obligated to interoperate with AMD at all. They could simply design their compiler to refuse to run on an AMD box. They could design their compiler to write programs that refuse to run on an AMD box.
AMD, in turn, could produce CPUs that claimed to be Intel CPUs.
This is no different from Ford deciding to use odd shaped cup holders and selling expensive replacement cupholders to prevent Repco from undercutting them.
What would be truly unethical and illegal would be what Microsoft did to Borland with Windows 95 betas -- incorrectly report errors after detecting a program compiled with a Borland compiler.
If Intel produces crashing code for AMDs -- that's basically a form of libel. Aside from that, I just don't see the problem.
They just refuse to turn on many optimizations unless they see "GenuineIntel" returned from the CPUID instruction. Thus excluding _everyone_ else.
At least they're being fair about it. *eye roll*
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
right now on this suit related to Apple saying "Intel" and not "x86" multiple times in press releases?
There end of story!
If it reports that it's present, you use the same goddamn code path. You don't check who the manufacturer is, you check what features the CPU supports.
AMD is a bit of a puzzle in the technology world. They've got fantastically gifted engineers, and fantastic products. But in a world where chest beating is as important as technology, AMD consistently cowers in the corner. Where are the ads proclaiming the very obvious (and ultimately most important) point that "AMD CPU's ARE SIMPLY FASTER" ?
People don't seem to realize that a 2.2GHz AMD CPU can spank a 3.2 GHz Intel chip. And why don't they realize that? Because AMD has some of the worst corporate communication skills in the tech world.
Just take a look at AMD's website. My highschool sister makes slicker websites.
AMD (God bless 'em and all their naivety) believes that better products alone will win the day. Newsflash guys: It ain't so. Faster chips alone won't cut it. They need to thump their chest and call Intel a bunch of sissies.
AMD Management: Please for crying out loud, hire an ad agency. Hire a PR firm. Open up a can of marketing whup-ass on your competition. It ain't like you're poor.
You simply aren't getting it.
You're stating as FACT that intel's compiler SHOULD make use of processor extensions on AMD chips. Why, what basis do you have...? Is there a legal requirement? Do intel advertise their compiler for compiling for AMD? Intel sell and market that compiler as producing top quality binaries for intel chips, which it does (although with recent versions less well on older Pentium models).
That simply isn't the case. Intel's compiler doesn't use the same extensions on their own chips that are earlier than P4. That's intel's choice, not yours and not AMD's.
There is NO reason that intel's compiler SHOULD produce code that runs at all on anyone but intel's chips.
Your points are all based on the fact that intel should be providing AMD with free tools - that's simply incorrect. It may be comunity minded to do so but it's still not a requirement, legal or otherwise IMHO, IANAL.
Also you state that the compiler should be checking for extensions and choosing to compile in functionality or not and go on to say that games companies do this with dll's.
Unfortunatley you don't seem to quite grasp the way the intel compiler works. You can compile in multiple code paths to the same executable that will be chosen at run time to suit the processor that it is running on. So intel do exactly what you're talking about, but the compiler does it for you.
The problem is that the code produced by the intel compiler treats any non-genuine intel CPU as being a basic i386. Fair enough, it doesn't have to run on them at all. This also saves them from masses and masses of potential compatibility testing and labs, all at intels expense with zero benefit to themselves.
Maybe intel should sue Apple for only providing OSX on Apple hardware? Apple here have a piece of software that only runs on their hardware but would be beneficial for intel if it ran across all their chips too, for every clone PC. Does that mean that Apple are required to provide OSX to Dell? No of course not!
Are you really suggesting that intel need to go to the effort of distinguishing all those different AMD chips, some of which identify themselves strangely? It's not fun, I know as I work for one of those aforementioned games companies and have had to do this.
We don't use the intel compiler BTW because of just this kind of problem with AMD's not being very optimal. That's our choice.
AMD shouldn't be suing intel over this, they should be making an effort to provide decent developer support and talking to developers that are shipping code that doesn't run optimally on their processors or balances better between manafacturers, not moaning about intel providing a compiler suite that works well for their processors.
"My opinions are my own, and I've got *lots* of them!"
And I've been very happy with it.
"My opinions are my own, and I've got *lots* of them!"
This seems to be it. I haven't tested it yet.
AMD is complaining that Intel deliberately complain that Intel's compiler favors Intel's chips for code optimization. Well, the last time that I checked, Intel spend the money to make the compiler so they have every reason to optimize for Intel's chips.
A good example would be two neighbors in a suburban neighborhood. The two houses' front lawns have no true dividing lines. But clearly it is two yards. One owner isn't obligated to water the other person's yard. He paid for the water and he has the right to favor his lawn as much as he want and setup his lawn sprinklers to favor his side of the yard and not his neighbors.
If his neighbor wants to keep his lawn green, he better spend the money to water his lawn and not cry fowl when his neighbor's water sometimes touch es his yard.
If AMD wants to optimize their code execution, then they are more than welcome to release a comparable compiler that is optimized on AMD, but runs a bit slow on Intel. Remember, Intel isn't compiling code that doesn't run on AMD, they just only play favorites on their own chips.
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?
Because "anyone" would know that certain code paths are going to be faster on both AMD and Intel processors than others. An SSE2 optimized code path is going to be faster on both chips than an x87 code path. Yes the chips are different but both do better with certain kinds of code.
Why would this be the case? Because AMD tried to make their SSE2 support as fast as possible so that it could run the same code as an intel compiler just as fast! AMD is not in a position to expect everyone to optimize their code for the underdog's processors. They have to make sure the code that exists runs fast.
Yes, they are going to be differences in the most optimal sequence of instructions depending on the microarchitecture of the chips. This does not mean that the optimal code path for Intel is automatically sub-optimal for AMD. Why would you assume that?
You don't see any fault because you aren't comprehending the situation. The CPUID instruction returns, among other things, a bit field detailing all of the instruction set extensions supported by the chip. AMD processors have supported SSE2 for years, and have this bit set. These instructions are quite fast on AMD processors, because they have to be. The Intel compiler produces code that uses SSE2, and other instructions if the compiler doesn't support it. However to determine which code path to use, the Intel-generated code uses the processor name returned by CPUID rather than the feature bits. It checks for "GeniuneIntel" or "AuthenticAMD", and uses either the fast code path or the slow one.
It has nothing to do with compatability, and everything to do with detecting and crippling a competitor's chip.
The enemies of Democracy are
``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.''
/.ers, but it makes a fine example case if you want to convince someone.
Which nicely illustrate why dependence on proprietary software is a Bad Thing. I don't think I need to point this out to
Of course, in this case, it's a difficult problem. Making good compilers (especially for an ISA as complex as x86) is hard, and something that volunteers cannot seem to achieve - or even the GCC team, which I do believe gets some funding. Intel at least achieves it for its own CPUs, but that leaves the other arches in the cold, even without sabotage.
Maybe we need some fund pooling for a truely great open source compiler, or maybe we just need to accept that suboptimal code is Good Enough, and wait for the next round of CPUs to get more performance...
Please correct me if I got my facts wrong.
Singular entity. Is Cmdr Taco from the US or Europe? In the US, company names are referred to as singular proper nouns.
At the cost of blowing away your icache? I think not. Cache pressure is the single most common cause of performance problems in modern code.
This is the only AMD claim that I completely disagree with. Intel is a chip company, not a software company. They only make compilers to leverage Intel CPU sales. Intel is under no obligation whatsoever to make their compilers work for AMD chips at all, let alone optimize them for AMD chips! While we're at it, why don't we sue Microsoft because Visual Studio won't produce code that will run on a Power PC, and won't produce code that will run under OS X... that's obviously anti-competitive behaviour too, isn't it?
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Since Theo is a license zealot, he would drop GCC for a portable C compiler if the license was right.
And GCC isn't portable?
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.
If you think that's impressive, you should see how entertaining he is at parties.
paintball
This is truly an old subject. Byte magazine showed this type of "optimization" and Dr. Dobbs has had numerous discussions on this over the years. Every CS major I was in school with in the early 90's saw this type of thing going on and we all just tossed the problem aside as Intel was the only real power in the x86 world at the time but I hope AMD has the fortitude to stick with this attack long enough to change a few things for all of us. I personally could care less who is "in the lead" as I am not a fanboy one direction or the other... I just buy whichever is more suitable at the time. However, the last time I ran in to this problem with Intel it was when I was putting together a recording studio for a client in Germany and we noticed that the Athlon ran the same code 30% slower than the Intel, even though the Athlon was at a higher clock and ran every other application 50% faster than the Intel. Again, this attack is long overdue from many people's perspectives.
I was wondering whether AMD's "daring and bold" assault on Intel will have any repercussions as far as the Intel/ms and AMD/ms relationships go. I know they flip-flop between bending over for ms and splaying for Linux/Open Source, but couldn't AMD benefit by having an outlet store selling AMD-based computers and Linux? Just an idea, but would this cause problems for them and msoft?
I ask partly because I'd heard that AMD is "deeply in bed" with msoft.
Don't they know Intel has the money to buy the jury too?
This has been in the PDF that AMD published on the day it made its lawsuit public exactly verbatim ever since DAY ONE!
Why does this become such a big revelation all of a sudden? Oh, right, i forgot: People don't read PDFs!....
What's more sad is that even ElReg didn't read it apparently...
They sell it as "the fastest compiler for x86 systems". It should work on any x86 system.
I am trolling
when you see the word 'Linux', drink!
According to this posting http://devforums.amd.com/index.php?showtopic=34&h
Also amd gives many hints on optimizing for amd cpus with the intel compiler in there Compiler flags document (PDF)
http://www.amd.com/us-en/assets/content_type/whit
It mentions that some specific optimization flags work for version 7.1 and 8.0 but not for version 8.1.
It seems that intel improves its amd-specific optimization with every version.
I could not find any other postings on this topic on the amd forum. You would expect people to post these kind of issues on such an obvious place.
Wimp
"Premature optimization is the root of all evil" Donald Knuth
Wow.
I've managed to read up to page 17 of:
l oadableAssets/AMD-Intel_Full_Complaint.pdf
http://www.amd.com/us-en/assets/content_type/Down
Now, for me, page 15 is where things begin to get "juicy". I would think that by now AMD would find all the AMD-friendly desktop/laptop computer makers it can and set up AMD outlets, a la Apple stores. With the profit margins so low on computers, and given that Intel is pushing AMD to the brink of "do or die" or at least putting oil on an already black-iced road for AMD, could it hurt AMD to just go "all out" and relentlessly push it's CPU's? I would hope or suggest they tap into Open Source developers and maybe take two courses of action:
1. De-geek many Open Source user applications 2. Push AMD and Linux hardware and computer arrangements.
After all, IFFF they are deeply in bed with msoft, then it's only a matter of time for Intel to assert a certain amount of "hypocrisy" on the part of AMD, when ms is a convicted and morally defunct monopolist. For any company to be in bed with ms when that company's intractable enemy also in bed with msoft probably spells the reality or likelihood of pissing off ms.
I'm not a compiler writter, but I do a lot hand optimizations in assembler everywhere appropriate.
What I have found with MSVC is that the code produced by the compiler is very inneficient. From my experience, I like to say it's philosophy is "Never use the same register twice." In other words, though a register may have a value needed, left over from a previous operation, the compiler will always fetch it again. I always realize significant speed ups with assembler, from a minimum of at least 10X to commonly 100X or more.
This makes me wonder if Microsoft uses the same compiler for their products? Perhaps they have secret compiler switches so that their products compile better? Or maybe they use the Intel compiler? Any thoughts on this?
What would be interesting to see is all the hardware review sites redo their CPU benchmarks with (hopefully) updated game/SPEC/3DMark/etc... binaries. I wonder what performance gains we'll see from these new binaries. (maybe this is why some of the benchmarks show that Intel CPUs are better?)
AMD is currently working with the Free Software communinity (including working with both SUSE and Red Hat) to improve GCC support on its platforms. At present, there are no direct contributions from AMD to the Free Software Tools, but that will change in the future.
When windows 3.1 had a heavily encrypted, decompiler registry sabotaging, evil code that directly did "if dr. DOS then emit fake error message" it was documented quickly.
It is odd that AMD doesn't provide a code example, that would help their cause's credibility immensely!
I mean, perhaps sheer incompetence and lazyness of the programmer in charge of testing the Intel compiler on AMD made him write that "if AMD then don't try optimizing".
I can see that happening if the lousy code path with undetected bugs ran fine for a day on an AMD and Intel not having a budget for testing if the optimisations ran fine too. While this is downright unethical to do it's not actually sabotage; it's called management.
That's completely different from actual sabotage.
Let AMD show us some actual code examples to see any actual proof of well-planned sabotage. Slashdot programmers aren't just gonna trust anyone's lawyer about this even if that lawyer is fighting a microsoft-behaved entity like Intel!
Or is AMD so low budget they can't even afford a programmer to work for their legal team for one lousy day? (-;
P.S.: I currently use AMD and love it.
Microsoft is pure dog-ma. FreeBSD is pure cat-ma.
Why can't AMD CPU's contain an Intel CPUID ?
Its not as if a CPUID represents any kind of legal trademark. As I understand its simply a bit set to 1. I'd love to see Intel try to claim that they own a trademark on that particular numeric value in that particular memory address.
Has anyone ever been sued for electronic-identifier infringement? In this particular case it would be seen as "performance enhancing code".
So why on Earth doesn't AMD just burn the Intel CPUID directly to AMD CPU's?
------ The best brain training is now totally free : )
He did it to show that even theoretical attacks, which have never been seen in the wild, can be effectively mitigated out of existence.
Never forget that the Open Source development community have been working towards providing more secure environments, whether you make use what is available is up to you.
maow.
All corporations are corrupt, greedy, despotic.
Details at 11:00!
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.
Maybe some benchmarks that have been run recently are compromised by this stupidity?
It should be possible to find out by looking at the binaries which "benchmark" programs are compiled with the Intel compiler.
For instance, many websites post FPS and other types of metrics from games and application programs as measures of real world CPU performance.
Perhaps AMDs performance is even better than the current reviewers claim.
AMD claims the Intel compiler INTENTIONALLY singles out AMD and compiles cumbersome, slow code for AMD CPU's.
Intel claims it does not.
But from everything I can see on this board... AMD has been extremely vague about whether or not the slower compile paths apply to "non-Intel chips in general" or "specifically to AMD chips". (The latter would indeed be grounds for a lawsuit).
But let's be clear: Intel would be perfectly within their rights to make a generic non-Intel option which functions at the level of the safest (albeit slowest) common denominator. To begin to optimize and troubleshoot for alternate (competitor's) chips would be an absurd project for Intel to invest resources in. The question is this: Is AMD uniquely singled out here by the Intel compiler? (By name?) Or does the Intel compiler check the CPUID for a simple boolean of Intel or non-Intel.
I've read all the linked articles here and I have to say that no one has provided a shred of evidence that Intel specifically cripples AMD chips. I'm no fan of Intel, but I have to say it sounds like they are simply:
a) writing enhanced code for their products.
b) ensuring cross-product compatibility at the lowest possible denominator.
Does this lowest possible denominator suck *so* badly that it is malicious? That may be a good question that a jury will have to answer.
------ The best brain training is now totally free : )
Have you ever used a computer? Or an MP3 player? How can anyone in this age think that the only difference between file formats is the extension: "Want to convert your html file to a Word doc? Just rename it from thisfile.html to thisfile.doc !!!"
" distinction that I'm sure is highly significant to you and perhaps five other people."
I'm sure it is much more than 5 million, not 5. Only an idiot newbie would confuse entirely different file formats.
Don't blame Durga. I voted for Centauri.
Or do you have some sort of super-sophisticated OS we do not know about it that performs such complex apples-to-oranges file conversion operations instantly merely by renaming the files?
Your idea that "an AAC is really an MP3 file with a a non-MP3 extension" is intriguing.
Don't blame Durga. I voted for Centauri.
So, Intel engineers put in more time, and had more knowledge and experience, on how to optimize code for Intel processors than for "Intel compatible" ones? Shocking! What is this world coming to?
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
GCC needs some serious work when deliberately crapified code runs faster than what GCC calls optimized. Let that sink in. GCC's output is so bad that even with optimizing isa extensions turned on, it's slower than bog standard stosb.
So was my Packard Bell Legend, with a 486SX 20Mhz. No fan in the system, and no heat sink on the CPU. Ran for years (with the lid shut) until I had a power surge that killed the PSU, which burned off several resistors and capacitors on the mainboard.
I overclocked it to 33Mhz and it still needed no fan. Back in 1991, nobody believed me at the computer shows when I told them all you had to do was set a jumper to make the CPU run faster.
- It's not the Macs I hate. It's Digg users. -
Intel will just say that they had different teams responsible for optimization for different chips. After that it is just logical that the most talanted guys were responsible for Intel chips.
Tradema...nevermind.
Too easy.
Assuming for a moment this garbage is true, who says Intel has to fairly support their *competition*? ( or at all )
Last i heard , they were not declared a monopoly ( i could be wrong here ), and if that is still true they dont *have* to do diddly.
---- Booth was a patriot ----
This question probally betrays my ignorance, but where's the AMD Compiler? Its true that free compiler may support AMD, but it would seem that AMD should invest in creating an optomising compiler for itself... perhaps one that can work as a drop-in substitute for Microsoft's in Visual Studio?
In any case, Intel clearly was under-handed here... but its just another case of them being bigger and more popular, but not better.
I suggest pressuring Intel with a class action lawsuit. I'm certain it's the only thing they'll listen to, and I doubt they'll even listen to that. You'll probably have to win your lawsuit.
Need a Python, C++, Unix, Linux develop
elsewhere in this thread.
It gives enough information that anyone with the compiler should be able to check it.
Somebody pointed out swallowtail.org's analysis. That analysis includes a description of how to patch around the check for the manufacturer string.
I might guess that many of those who use iNTEL's compilers already patch their binaries?
AMD have licensed the MMX, SSE, SSE2 and SSE3 (and other) x86 intruction set extensions from Intel and have functional implementations of those extensions in their various CPUs. This is so that AMDs CPUs are not placed at a disadvantage in the marketplace, and can compete in a level playing field, so for a program that uses MMX, SSE, SSE2 or SSE3, the program can use those extensions rather than emulating them.
Intel have a complier that makes use of those extension - but by default the compiled object code will only use the code path that implements those extensions if the object code is run on a Real Intel CPU - regardless of what instructions sets the CPU actually supports.
This is NOT about Intel supporting AMD's own extensions (3DNow!), or providing code that is optimised for the way the AMD CPUs actually carry out the instructions.
This is about a seemingly deliberate attempt by Intel to provide a compiler that only provides code that runs optimally on recent designs of their own CPU - at the expense of every other CPU design, even if those other designs support the same performance enhancing extensions that have been licensed from Intel! It requires deliberate checks in the run time object code to detect what CPU the code is running on - but instead of querying the CPU for which extensions are supported, the complied object code is querying for the CPU for its make and model, which is a sub-optimal method of checking for supported extensions, when the CPU can tell you directly which ones are supported.
Which brings us up the point about Hanlons's Razor "Never attribute to malice that which can be adequately explained by stupidity" . Either Intel's compier engineers are so incompetent as to use a clunky, unreliable method of CPU capabilty detection by CPU Make and model rather than the more elegant method of asking the CPU for its supported instruction sets, or the Intel Engineers are doing it through malice (or by Marketing Department Directive...).
In light of that, the outcome for Intel is not good - either their engineers are made to either look incompetent (I don't know about you, but I don't think that's good), or there Marketing Deparment are acting with malice against their competitors to mis-represent the performance of Intel CPUs with respect to its competitor's CPUs. (not good either)
Oh, and I noticed you'd posted as AC, but I've seen that on Slashdot if uncritical thinking goes unchallenged, it tends to run rampant...
I always buy AMD chips when I can just because I think they are cheap and good. In some cases I have compared performance but it hasn't ever affected my final decision on which one to buy.
Has anyone ever not bought an AMD CPU because they compared performance of a program compiled with intel's CPU and the intel CPU was faster, and that alone was the key factor in taking that decision?
...ad hominem?
I didn't think so.
I am so fucking sick of these stupid businesses suing these so called "monopolies" under the anti-trust act which is unconstitutional to fucking begin with. The reason why microsoft has such a large market share is because no one has been willing to come up with a god damned competing product that's worth something. I was a fan of AMD, but after making such fucking ludicrous claims, the next processor I will get is an Intel processor.
OF course, when you're the under dog and don't want to compete using pure capitalism, you bitch moan, whine and fucking cry to the god damned government for them to do something. AMD should write their own god damned compiler, Intel has every fucking right to cause the application to run slower, to crash if they want if it detects an AMD processor. Fuck, they even have every right to prevent the fucking software that's created on their compiler to refuse to run on anything but an Intel processor if they fucking choose to do so.
AMD need to fucking shut up, compete with Intel like they have been doing, or they're going to go belly up.
How is this anti-trust? Do Intel Compilers have a monopoly?
Let me make an analogy to explain this a bit. Its like if you had a motherboard from nvidia, say an nforce 4 motherboard. What if it looked for the presense of an nvidia graphics card, and if so, enabled AGP 8x, fast writes, etc, but if it found an ATI graphics card it only enabled AGP 4x etc, disabled fast writes. REGARDLESS of if the graphics card supported the agp 8x or not. Its ATI's responsibility with thier card to ensure it supports AGP 8x properly if they list it on their box. Its not the motherboard manufacture's job to arbitrarily enable and disable it based on brand alone. Everyone can see where that would be wrong and unfair to the competition (ATI).
Of course the code takes two different code paths for different processors! they have different instruction sets, and therefore optimization techniques for one differs from optimization techniques for another. why spend time optimizing your own software for the competitions hardware.
we are capitalists here! (i am anyway) why do we feel it's neccessary to help the limping competitor?
The difference is much more than just the file extension.
"us with your theoretically superior intellect and technological knowledge?..."
No. It does not take a rocket scientist to know that Apple does not deal in MP3 files at all, and that AAC files are not the same as MP3 files.
"as the term mp3s usually equates to music, at least in the common vernacular. "
Are you now making stuff up to cover your earlier mistakes in this? There is a big difference. Or, do you think that "VHS equates to movies", which makes it OK to confuse VHS with DVD?
"However, your apparently small and feeble mind has fixated on the three small letters at the end of the file name."
They are important, and make the statement that Apple gives away MP3's entirely incorrect. Once again you are saying that the only difference in the file formats is the extension on the end. You seem to be unaware of the basic tech issue of different file formats, and the incompatibilities which arise from them. Again and again, you say it is just a matter of the extension, and not the file content itself. Do you actually think that these mp3 files Apple gives away will play on most mp3 players? Since we know that they won't, are you still insisting that it is OK to call these files "mp3" when they won't even work?
"The point you seem unwilling or unable to grasp is that I, like quite a few other people, buy MUSIC, not file formats"
I am perfectly aware of that. However, the original incorrect statement about Apple actually referred to a specific file format, not "music".
"And as long as I have a reasonable expectation of fair use, which FairPlay grants, I could care LESS what format it's in. "
That is an entirely different subject. "FairPlay" does not grant a reasonable expectation of fair use. It is a kludge if I have to burn and re-rip from a CD, or seek out dubious Hymm programs in order to get it to a format that will play on my hardware. If Apple actually DID deal in MP3's, this would not be a problem.
Don't blame Durga. I voted for Centauri.
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.
I'm pretty sure that if you looked deep down into definitions, you'd find that an AMD system is "x86-compatible" rather than just plain "x86". Especially if you're reading Intel's dictionary and/or legal contracts.
Further, if that's the actual quote, that may very well mean that it compiles faster than any other x86 compiler... not that it makes faster code. Typical market-droid logic/doublespeak.
Yet, even with all these shenanigans going on, at $400, it's only about half of Microsoft's offering... Half the processor compatibility, half the price. Heh.
That's just not feasible. Unlike Intel, AMD isn't huge and they don't have a massive software team.
If I were an Intel lawyer, your post [and others like it] would be defense exhibit #1:
Good thing you aren't an Intel lawyer, since that argument does nothing to address Intel deliberately running slower code on AMD parts. "Write your own damn compiler" doesn't address the issue of Intel's compiler producing code that, despite the expectations of its users, avoids using extensions available on a processor because Intel doesn't like that processor. But good luck.
"Its users" are Intel customers, not AMD customers. If Intel were to guarantee the performance of their compiler on AMD platforms, then they would have to purchase and assemble a small warehouse full of platforms, and train and support a small army of specialists in those platforms. That's a huge expenditure in time and money and employee man-years, which is not Intel's responsibility: It's AMD's responsibility. And if Intel releases a compiler that includes a fatal bug on AMD hardware, then they could become legally culpable for any damage caused by that bug.
By the way, I use AMD CPUs exclusively. I just don't like this idea that Intel is responsible for everybody else's hardware platform, and that somehow Intel is supposed to provide all of these services to AMD for free.
Again, the obvious solution is for AMD to write their own compiler.
Would it be possible to patch affected software after market? If I purchased some software compiled with Intel's compiler and own an AMD processor it would bug the crap out of me knowing that it could be better.
There are thousands of cracks to defeat the copy protection in games. Could we see cracks that would unleash the full potential of AMD processors?
Would it be legal to do so? Would a software vender actually prosecute someone if they created or used such a patch?
I want this account deleted.
Never mind, I decided not to hire you.
Better get used to that.
The intel compiler though is no longer as bright as it once was since MS and gnu have both improved their C and C++ compilers. I admit on Windows gnu c/C++ still sucks but I have seen benchmarks which show the intel one being near in performance with the other compilers.
Fortran is different since the gnu one is based on ansi 77 not 90, and the portland group is the only company left even making commercial fortran compilers.
http://saveie6.com/