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.
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
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!
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!
...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.
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"?
Awww... A competitor's compiler is not optimized for our architecture. Cry me a river.
There is a subtle difference between "not optimised" and "goes out of it's way to slow it down".
A subtle, possibly criminal difference.
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..."?
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.
...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.
Part of AMD's claims is outrageous. Why would AMD expect its competitor, Intel, to write software that supports AMD's own products? We would not expect IBM to modify AIX or any other IBM software package to run on SPARC, which is a poorly designed processor.
1. AMD's claim is that the Intel Compiler produces code that actively detects the AMD CPU, then intentionally runs slower code. That's not the same thing as Intel optimizing their compiler for the Pentium Architecture.
2. If you think the SPARC is a poorly designed processor, you need your head checked.
By restricting the GCC compilers to generating only a simple but fast subset of instructions, we could encourage both AMD and Intel to deprecate and, ultimately, eliminate the more complex x86 instructions. Linux and the bulk of open-source software use the GCC compilers and would provide a critical mass of support for a new streamlined transistor-count-reduced x86 chips. Here, I am thinking, "shockingly reduced in power due to using 1/3 of the transistors."
Wouldn't that make the x86 Platform act like one of those "Poorly Designed RISC Processors" you were just complaining about?
In any case, you won't see much of a transistor reduction. Most of the instructions you're trying to avoid are implemented in MicroCode and add no significant overhead to the chip. What *does* add all the transistors is the 20 stage pipeline, branch prediction, superscalar execution, Out Of Order instructions, etc, etc, etc.
Javascript + Nintendo DSi = DSiCade
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.
I'm running a Venice 3000+ now. Really sweet. Fast as all getout.
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.
Personally, I think this is a bit of a grey area. Obviously, it seems wrong that Intel should be crippling software, but at the same time, they aren't making anyone use that compiler in the way they are making people not sell AMD products (maybe I'm wrong, I didn't read that enourmous legal document). Ultimately, this whole thing is secondary to the monopolistic discount allegations, anyway, so it would be nothing more than icing if it's true. It does make for a nice "they're big meanies!" finger-pointing fest, though, huh?
I'd rather be cycling.
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 {
+
}
************
And as a person who's designed a simple (can't do too much in 10 weeks) 2-issue out of order machine, let me tell you, that's fun stuff. Really makes you appreciate how insanely complex real processors are. And don't even get me started on their branch prediction...
I'd rather be cycling.
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....
There is a big difference between writing software that supports AMDs products, and crippling software so that it doesn't work with AMDs products. This would be sort of like having a car that detects the brand of gas that you use and either refusing to work or switching into low gas mileage mode if the "wrong" brand is used.
I don't practice what I preach because I'm not the kind of person that I'm preaching to.
"Why would AMD expect its competitor, Intel, to write software that supports AMD's own products?"
/. to support almost any form of sleazy behavior on the part of some corporation.
How about because Intel's compiler customers would expect Intel to do so?
It's hardly the same as refusing to allow your OS to run on another company's processors. If you don't want your compiler to support AMD, engineer it that way and say so to your customers. Building in stealth methods of sabotaging performance on the CPU is hardly the way to go (if in fact that is what Intel did without good engineering reasons why.)
Did you use to work for Enron or WorldCom by any chance?
Do you work for Microsoft?
I'm amazed at how you can find shills on
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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?
"Those who are too smart to engage in politics are punished by being governed by those who are dumber" -- Plato
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.
Well, if it's the case that the compiler just didn't optimize for competitors' processors, then I'd agree with you. However, in the event that Intel took the time to code their compiler to intentionally degrade performance on competitors' processors, then I'd have to strongly disagree with your point.
english is my first language, but my only formal education in it was from U.S. public schools, so you may forgive me for
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.
"run on SPARC, which is a poorly designed processor"
I know this is Slashdot, but do you have anything to back this up. Everything I have read about SPARC seems to suggest that it is a very well designed processor although manufacturers seem to have failed to push uit to the MHz that Intel and AMD have achieved.
You also overlook the fact that SPARC is not owned by an individual manufacturer but by the SPARC Consortium. This means that the AMD / Intel issues described in this thread simply could not exist as everything is genuine SPARC. I recently bought some Fujitsu PrimePower SPARC boxes in preference to SUN boxes, they are certified by SUN to run all versions of Solaris and indeed they are currently running Solaris 9 like a dream. In addition they are outperforming some other manufacturers XEON boxes we also use to run JAVA software on an out and out price comparison basis and have had 100% relaibility of 16 months, not something I can say for every Linux / XEON box I have use (based on a very small sample size of 3 PrimePower to 5 XXX Vendor XEON, so take with a pinch of salt).
SUN's roadmap for SPARC continues to look very good and their low end boxes compete very favourable with even their own AMD based boxes. So I remain confused as to what's not to like, I will certainly be bying them again (especially with Solaris 10 shaping up very nicely).
Isn't Prescott 32 stages nowadays? Silly Intel. Gotta have the bigger pipeline, huh?
;-)
Indeed. Only Crays and DSPs used to have pipelines that long. A single jump instruction, and you have to flush the entire pipeline! In super-computing and DSP, you almost never see a jump, so there's no concern. But in Intel's zeal to win the clock rate wars, they maxed out the pipeline to an absolutely ungodly length. And a 2.2 GHz AMD64 *still* outperforms a 3.2 GHz Pentium!
Seems that Intel's P4 design backfired on them. Of course, that may be due to Intel's belief that the Itanium would take the market by storm. They did learn from their iAPX 432 chip by at least producing a method for emulating x86, but they failed to take into account how deeply entrenched the x86 performance crowd was. Now AMD64 is eating Intel's lunch! (Oops!)
And as a person who's designed a simple (can't do too much in 10 weeks) 2-issue out of order machine, let me tell you, that's fun stuff. Really makes you appreciate how insanely complex real processors are. And don't even get me started on their branch prediction...
I hear you. Trying to cram a reasonable chip into an FPGA can be quite a challenge. If MicroCode hadn't been invented, it might not be possible to fit one in so few transistors. At least we can finally stop the CISC vs. RISC debate. The MicroCode designs provide CISC instructions on top of RISC cores just to confuse the heck out of both sides. Next up, writing a VI clone in LISP!
Javascript + Nintendo DSi = DSiCade
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?
The most likely reason for this is that the compiler doesn't recognize the chip at all, and says "oh, this is probably some really old Intel chip, so I need to ensure compatibility with CPUs back to the dawn of time." I doubt it's an intentional attack on AMD. It probably isn't explicitly detecting AMD's chips so much as falling through the default case of a switch statement or something....
Just my gut feeling.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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....
It's very simple. If I were a programmer buying Intel compilers (I mostly do administrator work) would I have been reasonably led astray by their advertising to think that what Intel was selling was an X86 compiler that didn't play favorites? There's an enormous class action waiting out there for programmers who thought they were getting something (an honest x86 compiler) but werent and had to deal with user complaints from customers who suffered. There's a similar end user class action just waiting for an enterprising lawyer to set up.
End users and programmers have no interest in supporting Intel processor dominance but were tricked into that by Intel's underhanded dealing.
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.
Which is, per antitrust legislation in the US, illegal.
I currently have no clever signature witicism to add here.
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
As others have pointed out, Intel allegedly went out of their way to secretly hobble code on AMD CPUs. Normally, there would be nothing wrong with pulling a dirty trick like this.
However, this is an *anti trust* case. If you are hold a monopoly position in a market, you are prohibited from taking advantage of that position in various ways, and that may very well include this particular dirty trick.
http://www.swallowtail.org/naughty-intel.html/.
A single jump instruction, and you have to flush the entire pipeline!
That's patently not true
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.
Dude, if you have a patent on falsehood, enforce it.
These days, you'll be making Gates look poor, an' junk.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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. :)
Intel supporting or not supporting AMD is completely different than deliberately targeting AMD for poor compilation. Something along the lines of:
if (cpuid == "Genuine Intel") compileOptomizedBranch();
else if (cpuid == "Authentic AMD") compileCrappyBranch();
else compile();
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
Hi akaimbatman, we meet again ;)!
Frankly I am not into the compiler world (I'm no C/Fortran programmer), so I didn't expect that programs compiled with the Intel compiler would even try to work on an AMD CPU. I'm not at all surprised. These are just candies on a big, stinky cake.
Sure if this kind of behaviour is not documented, and the ICC is advertised as "AMD compliant" it is a plain swindle.
-- Patent no.123456: A way to personalize
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.
The mods are on crack, how you got modded up is beyond me.
Part of AMD's claims is outrageous. Why would AMD expect its competitor, Intel, to write software that supports AMD's own products?
Well it supports the x86 architecture. It doesn't have to support special features of AMD, but it should not purposely run different code (than it would on an intel proc) to crash the system. That's pushing the limit on anti-competitive, next thing you know ford is selling fuel that runs great in their cars but can tell if it's in a toyota and decides to spontaneously combust in the tank then.
Oh yeah, on the SPARC note, you need to take a computer arch class if you think that they are poorly designed.. if anything the x86 arch is the biggest hack of all.
On a related note, is there any way by which the authors of the GNU compiler collection (GCC) would limit the range of x86 instructions generated by GCC compilers....
Once again you have obviously never taken any classes regarding the subject. So you want to force all cisc processors to become risc by changing gcc to only support simple instructions? (which are not necessarily faster, just look at the cycles some complex operations take then try to create something in asm that does the same in the same amount of cycles using only simple instructions). Have you forgotten that GCC is not the only compiler in the world? Did you not RTFA?! It's about the intel compiler for goodness sakes! If GCC was crippled as you suggest, no one would use it, end of story.
Oh and less transistors on a chip? Brilliant. I assume you don't want faster computers or something. All the advanced branch prediction, out of order code execution etc that makes todays processors process that much faster than previous ones is thanks to the extra transistors.
If you want to talk about how computer architecture should change, take at least one class in it. It is really interesting (believe it or not) and you would learn a lot about what has been tried and done and why certain choices were made.
"If you are going through hell, keep going." - Winston Churchill
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.
Hi akaimbatman, we meet again ;)!
;-P
:-/
(rolls eyes) You again.
Frankly I am not into the compiler world (I'm no C/Fortran programmer), so I didn't expect that programs compiled with the Intel compiler would even try to work on an AMD CPU.
That would be a perfectly acceptable answer, and the one that AMD would like. However, the Intel compiler is not just producing highly optimized code and leaving it at that. Highly optimized code would work fine on an AMD CPU, partly because AMD has a technology cross-licensing contract with Intel. (Which means that Intel could produce AMD64 CPUs if they wanted!)
The core of the issue is that the code generated by the Intel compiler uses the slowest code path available if the CPU is an AMD. That's a potential Anti-trust violation, and smacks of desperation on Intel's part. I've always been overall happy with Intel's handling of their monopoly, but Moore is no longer at the helm and I fear that Intel may be slipping.
Javascript + Nintendo DSi = DSiCade
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?
A single jump instruction, and you have to flush the entire pipeline!
:-)
That's patently not true
Fair enough. A single mis-predicted jump will flush the entire pipeline.
Thanks for the correction.
Javascript + Nintendo DSi = DSiCade
...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.
Why would AMD expect the Intel compiler to produce optimized code? because of theis from Intels websight.
"Accelerate Windows* Applications
Develop high-performance software for desktops, servers, handheld devices and mobile phones that is optimized for Intel® architecture using Intel® Compilers for Windows*."
Note is says Intel architecture, which AMD processors are compliant with, not Intel processors. Therefore, I would reasonably expect that claim to be substantiated in the resulting code.
I see it also creates spelling errors, too.
God, I totally forgot how to spell. That will teach me to type while eating lunch and running server diagnostics in another window. Not enough synapses for all of that at once.
If they put a warning in the EULA for the compiler about it not being efficient in non-Intel processors, then Intel would definitely be in the clear, but if they sold their product as simply a vanilla x86 compiler, then they've got shit to be responsible for.
Learn something new.
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.
And you have to add:
The branch predictors are fucking great, nowadays.
Real world prediction rates >98% are not unheard of, meaning only 1/2 or 1/3 clock additional execution time per jump instruction in average.
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
"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!
Sorry to say this, but you have been trolled.
I might get modded down for telling you this, but it's worth it if we can avoid a long thread about SPARC.
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.
There isn't anything really poorly designed about the SPARC, which isn't to say it doesn't have some things nobody would put in a new CPU. For example it is one of only 2 commercial RISC CPUs with register windows (the other being the ill-fated AMD 29k), so I doubt anyone would do that again. It has (optional) branch delay slots, which were a win for a few years, but on OOO CPUs you can get the same gain without the pain. It also has a MULSTEP instruction, which is pretty much a waste when you have the transistor budget for a real multiplier.
All of those can be forgiven as either actually a good idea in the late 80s, or at least not a known to be bad idea. Even the much maligned register stack was a pretty effective cache with way fewer transistors for a while there.
SPARC hasn't suffered because it was a crap design, it has suffered because it doesn't have the same volumes the x86 does, so Intel putting $0.02 per CPU back into R&D gets it a bigger R&D budget then Sun pouring $1000 per CPU back into R&D. Disclaimer: I made those numbers up. Totally invented.
> 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.
And these branch predictors come at the expense of higher transistor counts, more heat, and the fact that >98% is not good enough to make up for the fact that your pipeline is *twice* the depth of your competitors'.
The P4 quite possibly has the best branch predictor out there right now, but that doesn't make up for the fact that it *still* underperforms compared to AMD's chips.
"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.
Why shouldn't they?
Face it: Intel is playing a dirty trick that would be legal if it didn't have such a huge market share.
"I don't know, therefore Aliens" Wafflebox1
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...
I think my car already switched to that mode. I never thought about changing brands. Thanks!
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?
Only if the "right" gas company was one making the car. Not exactly a great analogy there...
If you are expecting something here, I don't know what to tell you...
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
No problem! I just thought you had a bad accent.
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.
I'm amazed that you're amazed. This is /., after all.
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.
Show me one fixed-point DSP with anywhere close to a 32-stage pipeline.
It is rare to see fixed point DSP pipelines longer than 12 stages, and most of that is just memory latency. That's short compared to just about any modern microprocessor.
Not even floating point DSPs, which are irrelevant; nobody uses them. Well, maybe not nobody, but certainly the vast majority of the market is fixed-point with 16x16 multipliers. Pipelines for modern versions of these DSPs are usually in the 5-12 stage range.
Perhaps you are thinking of graphics pipelines?
-- Erich
Slashdot reader since 1997
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.
And I'm amazed by the number of people who assume that anyone who disagrees with them must automatically be a shill. Of course, no rational person could possibly have a different perspective on such things...
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
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."
Hello, did someone say "Vi clone in LISP?"Ya mean, like that?
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
"2. If you think the SPARC is a poorly designed processor, you need your head checked."
If you don't think SPARC is a poorly designed processor you need to wake up from your trendy x86 bashing and smell some benchmarks done in the last 5 years. SPARC hasn't been competetive for a long time. The only reason it's still around is because of Solaris and the fact that it scales well when you want to use a very large number of processors. But with Sun investing in Opteron technology they will likely stop making SPARCs soon. They've already stopped developing future SPARC designs.
Physics is good
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.
Um...do you always use corporation to mean unethical company? It's quickly become run of the mill agenda-speak. I'm amazed that how you can find shills on /. to reject almost any form of behavior by any business as 'evil' because it has to do with the word 'corporation' (which so many seem to have forgot the meaning of).
I haven't read all the legal complaint from AMD (TFA), and IANAL, so I can't speak definitively on this...but are you sure that Intel was acting in a nefarious way here, or just assuming it? If Intel's compiler simply disables propritary optimizations for non-Intel processors, there's nothing wrong with this. Intel shouldn't be under any obilgation to research their competitor's propritary optimizations and then support those with their compiler. There are other x86 compilers out there, right?
That being said, if Intel's intentions were nefarious, and deliberately attempted to slow code on their competitor's chips, sobeit -- they deserve to be punished.
So -- what evidence do you have as to Intel's intent? Are you only citing the AMD complaint? It was quoted in the summary, but are you sure that performance is only degraded if "Authentic AMD" is detected, or will it not apply Intel optimizations to any chip without "Genuine Intel" the CPUID? AMD's claim sure sounds open to some interpretation...and we all know that lawyers love to stretch the truth as much as possible, even if it is just a semantic technicality (ie: a conditional looks for GenuineIntel under CPUID and doesn't find it...in this case, AuthenticAMD != GenuineIntel and thus doesn't get the optimizations. Is this deliberate and nefarious, or just a lack of support someone else's technology?).
I sure hope that you're not basing your entire judgement of Intel (and your subsequent judgement of anyone who poses any doubt to this) on AMD's legal claim, with absolutely no other supporting evidence. If this is the case, do you work for AMD, by any chance?
I'll say again, just so there's no misinterpretation...I do not know anything about Intel's motivation or actions. If they've used their position to act against AMD, they deserve to be punished. However, if you're just using AMD's complaint againt Intel as 'fact' for judgement, then I've got some beachfront property in Arizona to sell you...as well as a few bridges.
-Turkey
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.
If you don't think SPARC is a poorly designed processor you need to wake up from your trendy x86 bashing and smell some benchmarks done in the last 5 years.
Do you actually know what you're talking about? Benchmarks have nothing to do with the validity of a design. In fact, they prove absolutely nothing since the SPARC is targetted at a very different market than the x86.
Put this in your head and think about it: A CPU is but a single component in a much larger system.
When you figure out how that relates to the x86 and SPARC architectures, let us know.
Javascript + Nintendo DSi = DSiCade
What Cray processor are you thinking of? I think you're confused.
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!"
Actually, the K8's branch predictor is better. The Pentium M has probably one of the best branch predictors.
Intel's CPUs outperform AMD's at a number of things. Intel loses big at the x86-64, because it's a stop-gap implementation. It loses at x87 performance, because the architecture was designed to favor the use of SSE. If you look at benchmarks, most stream processing favors Intel. Their implementation of SSE is better than AMD's as well. Once Intel adds an on-die memory controller, it will see the same handsome performance benefit AMD did. It's rather lame to use "underperforms" to compare them. They both have different strengths.
The biggest problem with the P4 isn't its performance, but the absurd amount of heat it produces.
The NetBurst architecture was designed to scale to high clock speeds, but Intel's process couldn't be scaled to meet the plans of the architecture. Intel has realized that previous process scaling methodology is no longer going to work, because leakage is just so bad. That's why the descendents of the Pentium M will replace the current P4.
But in Intel's zeal to win the clock rate wars, they maxed out the pipeline to an absolutely ungodly length.
The fools! All they needed was a built-in clock divider. They could have been delivering 128-GHz processors years ago. PHB types would have been saying "Wow! A 128x increase in speed--we've gotta get some of those!"
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.
Actually it says right on the compiler that it only optimises for Intel CPU's.
And lets set the point straight there is a difference between using a generic method of doing something that works on every cpu, and detectnig an "AuthenticAMD" cpuid and filling your code with things that wasted time. If they really wanted to be evil they could have porposly put out code filled with delay loops and other annoying stuff.
Instead Intel just put out generic code.
It's called emacs
The fools! All they needed was a built-in clock divider. They could have been delivering 128-GHz processors years ago.
:-)
There are *so* many things wrong with that joke. For one, I wouldn't be surprised if most motherboards today use a clock multiplier so that they don't need such expensive oscillators. Significantly increasing the multiplier would only serve to destablize the signal, resulting in a very poor wave after you divide it. The other problem is that the CPU is measured by the clock rate it actually runs at, not the rate of the crystal. Sorry.
Javascript + Nintendo DSi = DSiCade
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
== YAY for Cyrix and Transmeta!!!!!
Oh wait. compile(); probably just means compileMediocreBranch();...
Karnal
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.
Um, no they didn't. It segfaults on AMDs - does say that in the fine article, iirc
Semper en excreta sumus solum profundum
Don't they know Intel has the money to buy the jury too?
I'm curious - if Intel checked if it was an AMD chip and just refused to compile code at all, would people be up in arms? I doubt it. I don't think Intel is under any obligation to make compilers that work for AMD chips at all, never mind optimize for them.
Random is the New Order.
If you don't think SPARC is a poorly designed processor you need to wake up from your trendy x86 bashing and smell some benchmarks done in the last 5 years. SPARC hasn't been competetive for a long time. The only reason it's still around is because of Solaris and the fact that it scales well when you want to use a very large number of processors. But with Sun investing in Opteron technology they will likely stop making SPARCs soon.
I'm not sure that they ever did develop SPARC processors completely? I know that TI did/does sparc processors for Sun. And I believe that now (or the near future) that Fujitsu will be Sun's primary CPU vendor
They've already stopped developing future SPARC designs.
Also, isn't the SPARC CPU is a pretty open CPU
http://www.sparc.org/
compared to the intel/amd CPU's??
And there are quite a few companies that make SPARC based systems other than just Sun like
Tadpole
RDI
Fujitsu
Rave
NIS - I am typing this on a NIS UltraSparc II system
Aries
I know that there are others but that is all I can think of
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.
> Next up, writing a VI clone in LISP!
It's called viper-mode, and Emacs has come with it included for years. (If you don't understand why Emacs has to come with a vi clone included, then you clearly don't understand Emacs.)
Cut that out, or I will ship you to Norilsk in a box.
As I indicated in my post, I'm NOT assuming Intel is guilty. I'm just saying that if in fact they did not have good engineering reasons to do what they did, then it's sleazy behavior.
As for the poster who says the compiler docs say it doesn't optimize for other processors, that's fine if that's ALL it does. I doubt AMD is filing a legal case based on that simply because it would be easy to disprove and get the case thrown out of court. I make no assumptions, but it seems likely to me that AMD has some engineering reasons for saying the lack of optimization is in bad faith.
As other posters here have suggested, failing to use CPU facilities that are in BOTH the Intel and AMD architectures would seem to indicate at least a considerable lack of interest in providing compiler performance to their COMPILER customers running on AMD as opposed to their CPU customers for reasons of protecting their CPU business. If true, this would likely be considered anti-competitive behavior by the courts.
"will it not apply Intel optimizations to any chip without "Genuine Intel" the CPUID?"
And who else is a significant competitor to Intel except AMD? Fujitsu?
As for corporations being unethical, I go further than that. Most humans are "unethical". As Robert Ringer pointed out once, every human draws the line between "right" and "wrong" so that his actions fall on the "right" side of the line. I don't bother talking about "right" and "wrong" - I talk about "correct" and "incorrect." By that criteria, yes, most corporations suck rocks.
As for the "meaning" of the word "corporation", a corporation is NOT a "company". A "company" is a group of people heading in the same direction and providing mutual support and dealing with the outside world as a group. A "corporation" is a state-created entity which has legal protections not available to individuals. Ipso facto, from my view, the corporation is "evil" since it would not exist without the existence of the state - which almost by definition is "evil" (not that I take the term "evil" to have any more meaning than the words "right" or "wrong" - the effects of the state are universally bad, however.)
I don't assume every corporation is behaving badly by intention. In some cases, they behave badly by stupidity and incompetence. There may even be some corporations run by reasonably well-meaning and competent people - very few, in my lifetime experience. Certainly most of the big ones succumb to sleazy behavior at some point. Why trust them until you know otherwise?
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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 : )
"Instead Intel just put out generic code."
Is this an assumption on your part? Have you seen the source code?
And apparently there is some question over whether Intel's compiler bothers to optimize when optimization features are present in BOTH Intel and AMD architectures. This might be attributable to laziness or incompetence, but it might also be more than that.
At the very least Intel compiler users who run on AMD should feel slighted if Intel did not bother to optimize code everywhere it could do so safely simply to protect its CPU business.
Who's right depends on an impartial engineering analysis of the compiler. Without the source code, this may prove difficult. Presumably AMD will demand exactly this - analysis of the source code by a court-appointed independent group - much like has been done in the IBM vs SCO suit. It will be interesting to see whether two opposing groups of analysts will come to opposite conclusions.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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!
1. AMD's claim is that the Intel Compiler produces code that actively detects the AMD CPU, then intentionally runs slower code. That's not the same thing as Intel optimizing their compiler for the Pentium Architecture.
The problem with this claim is that it's not actually true! I hate to ask this, but have you checked what happens when you use the Intel computer on a system powered by a VIA CPU? That's right - you end up running "the slower code". What the Intel compiler does is check for certain lntel CPUs - it certainly does not target AMD CPUs. (If you think it does: show me the code emitted by the compiler. This shouldn't be hard like it was with the SCO case, since you can download the compiler free for noncommercial use.)
Of course, it doesn't help AMDs argument one bit that there are non-Intel, non-AMD CPUs such as those from VIA which are actually great little (and cheap!) CPUs that do encryption really fast these days. They make for awesome FreeBSD home/office firewall/webserver/proxy boxes!
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.
Actually this fine article says "it executes a different code path that will degrade the program's performance or cause it to crash." but gives no example. Just like SCO claims IBM infringed on it. However I doubt it causes it to crash on purpose or we would hear lots of people complaining about programs not working on thier AMD's. Compilers are tricky.
Except that one of the examples sited was that AMD processors run a gauranteed compatible chunk of code that uses no MMX instructyions. The compiler simply doesn't recognise it and defaults to code that will run on anything, which means it can't use MMX registers, etc.
As for
"At the very least Intel compiler users who run on AMD should feel slighted if Intel did not bother to optimize code everywhere it could do so safely simply to protect its CPU business."
I guess I would say to those people use another compiler. Or if you really want to use the Intel compiler use the Intel chips. I am glad that Intel did not waste time supporting other peoples chipsand instead made theirs as fast as possible.
but if they sold their product as simply a vanilla x86 compiler, then they've got shit to be responsible for
If so, the compiler customers might have something to sue about. Whether it is illegal under antitrust is a different question.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
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.
You're missing the point. If Intel did what you said and made it so the compiler simply did not compile code for AMD based processors at all, people wouldn't be as concerned. Why? Because it would be quite obvious to anyone that tried to use it that the compiler didn't work for AMD CPU's, end of story. However, in this case what's happening is that when it comes to AMD CPU's, the compiler is still compiling, but it's also purposly making an effort to slow the AMD CPU, all without indicating that to be the case.
It's this misleading part that people are so angry about. Had Intel openly stated that their compiler would not work as efficiently with AMD CPU's, then Intel may have been ok.
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.
Which means that Intel could produce AMD64 CPUs if they wanted!
From what I understand, the agreement didn't apply to the AMD x64 chips. Intel had to enter into a seperate agreement in order to get its hands on enough x64-tech to build the emulation layer used by the EMT64.
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.
Yes, one could tell those people that.
But I think they'd prefer to have been told IN ADVANCE BY INTEL.
Presumably they use the Intel compiler because it's the fastest and also presumably many are writing code they would like to see run equally or at least acceptably fast on AMD. If in fact Intel concealed an attempt to run slower on AMD, they are defrauding their compiler customers who are in the situation specified. It's really that simple.
Whether it was in fact done deliberately or not is a matter for court-appointed analysts to determine.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
You are forgetting the fact right on the site for Intel compilers it says:
"Deliver outstanding performance by optimizing your applications for Intel® processors."
It says nothing about "Will also optimize for any other processor you might have around the place."
So should I be mad at NVIDIA that they don't make drivers that work on my ATI video card? Thats just being a corrupt corporation!
First of all, the Web site is making marketing speak to get people to use the Intel compiler on their Intel processors. If Intel didn't want people to use their compiler on AMD processors, they should have said plainly "Does not execute properly on AMD" or "Not for use on AMD processors." Obviously therefore they DO expect people to run their compiler on other non-Intel architectures.
And if they didn't want to optimize on other processors, they could have said equally plainly, "NO optimization done on anything but Intel processors." Which obviously would have led most people to NOT buy their compiler if using AMD.
So if they then deliberately sabotaged those other architectures (and I repeat, I'm not saying they did), they are guilty of fraud to their compiler customers.
Secondly, the comparison with NVIDIA vs ATI is not relevant. They are two competing architectures, but the drivers make no sense outside of their respective architectures, by definition. Drivers are not compilers. You're seriously reaching here. It's the same as the AIX on Sun argument but more so.
Operating systems other than Linux are used to drive sales of hardware, not the reverse (which is why Linux will bury Solaris, AIX, and HP/UX once it gets enough enterprise-class capabilities). If Intel wants to use compilers to do the same, they should do so openly, not with anonymous hacks (if in fact they did so, which, I repeat, I do not know.)
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
So coders now need to buy a compiler for each x86 compatable chip the code is to run on and maintain as many code bases, and aplications need to have binary installs for each x86 class chip?
Shit like that belongs in the 1970s.
Well I've wrestled with reality for thirty five years doctor, and I'm happy to say I finally won out over it.
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/
Then buy a generic compiler instead of one built by and for Intel. If you don't need the enhanced speed the Intel compiler can give you on Intel processors don't use it.