Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AMD Alleges Intel Compilers Create Slower AMD Code

CmdrTaco posted more than 9 years ago | from the getting-a-little-spicier dept.

AMD 912

edxwelch writes "In AMD's recient anti-trust lawsuit AMD have examined the Intel compiler and found that it deliberatly runs code slower when it detects that the processor is an AMD. "To achieve this, Intel designed the compiler to compile code along several alternate code paths. ... By design, the code paths were not created equally. If the program detects a "Genuine Intel" microprocessor, it executes a fully optimized code path and operates with the maximum efficiency. However, if the program detects an "Authentic AMD" microprocessor, it executes a different code path that will degrade the program's performance or cause it to crash.""

cancel ×

912 comments

Sorry! There are no comments related to the filter you selected.

Simply ludicrous (5, Funny)

DeadSea (69598) | more than 9 years ago | (#13042874)


That is an outragous claim! No company would stoop so low. Why, that would be like claiming that Microsoft configured its servers to give broken HTML to browsers other than Internet Explorer. That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. That would be like saying that Adobe publishes pdfs that b0rk XPDF.

Anybody can see that this claim is ludicrous and that things like this just don't happen. (but I hope I'm not giving anybody any ideas.)

Type your currency conversion into a free form text box

Re:Simply ludicrous (5, Funny)

cwebb1977 (650175) | more than 9 years ago | (#13042928)

Hey, Microsoft doesn't even know the difference between correct and broken HTML!

Re:Simply ludicrous (5, Funny)

ssyladin (458003) | more than 9 years ago | (#13042955)

Neither does Slashdot.

Re:Simply ludicrous (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13043049)

Well that's not really the case. The slashmillionnaires would know the difference if they would acknowledge that the system is badly broken. If you were taco, raking in millions on this slow, lumbering, obsolete dinosaur, why would you change it? The revenue stream is only getting bigger. Why would you change it now? Progress? Hell, I've got my millions, why the hell do I need progress? Is it going to make my boat any bigger? Will it put more gold plating on my Ferrari? Fuck no, and therefore everything is working just perfectly.

Regulators Raid Intel Offices (4, Informative)

dsginter (104154) | more than 9 years ago | (#13042930)

In other news... [yahoo.com]

They'll probably be convicted and then buy the regulators like MS so they only get a slap on the wrist.

On that note, was there *anything* negative that came of the Microsoft monopoly ruling?

Re:Simply ludicrous (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#13042946)

pfft... like it matters... who uses Microsoft servers anyway? who uses an MP3 player besides an iPod?

Re:Simply ludicrous (0)

Anonymous Coward | more than 9 years ago | (#13043009)

I have and still use an original Rio Volt 120 cd mp3 player, one of Creative's 20GB players, and a Sans mp3 player memory stick player.
Why should I pay 3x market price for a logo of a half-eaten piece of fruit?

Re:Simply ludicrous (5, Interesting)

RootsLINUX (854452) | more than 9 years ago | (#13042951)

Well, I don't think they would make such a claim without at least some sort of evidence. And we all know that Intel is a corporation that doesn't like to play nice with the other kids. During my senior year of undergrad my computer architecture professor consistently refered to Intel as "the evil empire", so who knows. I'd like to see AMD present some hard evidence though.

Re:Simply ludicrous (5, Funny)

wo1verin3 (473094) | more than 9 years ago | (#13043040)

>> Well, I don't think they would make such a claim
>> without at least some sort of evidence

We agree.

- darl

Re:Simply ludicrous (1)

Calyth (168525) | more than 9 years ago | (#13043002)

Maybe I'm an uptight SOB, but Microsoft manage to make IE non-compliant enough that servers often send out HTML that doesn't render properly for compliant browsers. I thought I saw jhymn have to strip the info off a free AAC given away by iTMS, and I've tried to read PDF that's fscked up in xpdf/gpdf....
oh wait.... hardy har har

The Limit of Lawsuits (-1, Troll)

reporter (666905) | more than 9 years ago | (#13043150)

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. Sun Microsystems can surely whine about IBM's tactics, and Sun has definitely whined. However, IBM is well within its rights to withhold software support.

On a related note, is there any way by which the authors of the GNU compiler collection (GCC) would limit the range of x86 instructions generated by GCC compilers? Some instructions are simply too complex and could actually be replaced by sequences of simpler instructions, and each such sequence would actually run faster than the original, more complex instruction. A simplified subset of the x86 instructions is sufficient for compiling all computer programs.

By restricting the GCC compilers to generating only a simple but fast subset of instructions, we could encourage both AMD and Intel to deprecate and, ultimately, eliminate the more complex x86 instructions. Linux and the bulk of open-source software use the GCC compilers and would provide a critical mass of support for a new streamlined transistor-count-reduced x86 chips. Here, I am thinking, "shockingly reduced in power due to using 1/3 of the transistors."

Re:Simply ludicrous (1)

10000000000000000000 (809085) | more than 9 years ago | (#13043153)

Really, the question is why do people do this?

How can people that make such stupid, short-sighted decisions work in sectors of the economy generally associated with intelligence?

this goes for scientific skewing as well.

WHY?

perhaps not enough people realized that happiness==success. not money.

How can this be done? (3, Interesting)

haluness (219661) | more than 9 years ago | (#13042876)

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?

Re:How can this be done? (1)

bdow (67803) | more than 9 years ago | (#13042909)

fool the detection and then compare results on the same hardware

Re:How can this be done? (1)

91degrees (207121) | more than 9 years ago | (#13042964)

No need to try to fool it. Simply run it on two different processors with the same compiler flags. The code created should be identical. Compilers should not be designed to assume software is going to be run on the system used for compilation.

Re:How can this be done? (4, Informative)

Roland Piquepaille (780675) | more than 9 years ago | (#13042948)

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?

Usually by decompiling the code produced. AMD probably made a test program, compiled it, found a chip test routine in the resulting binary, then decompiled the 2 code paths it could follow.

For example, the "intel" code path could, for example, make full use of the math coprocessor to perform a division, while the "non-intel" code path could use only the 16 bit registers and make multi-precision divisions with only the basic x86 instruction set. I'm sure the actual de-optimization (if it occured) involves higher, cleverer functions than just divisions, but that's the general idea.

Re:How can this be done? (1)

retsaMedoC (107951) | more than 9 years ago | (#13042967)

Well, considering that the AMD parts they are talking about are based upon Intel's x86 standard, the compiled result should be pretty similar if not exact when compiled with Intel hardware. That would explain differences in compliation. Stability and speed could be checked with a few benchmarks.

Re:How can this be done? (4, Informative)

pcidevel (207951) | more than 9 years ago | (#13042974)

Because a compiler just spits out machine instructions, it's a trivial task to compare the instructions from one code path to another.

For example, you write some code that would typically use SSE2 regisers when compiled, then you compile the code for each processor, and check to see if it used SSE2 registers on each, or if it ouput slower "emulation" style instructions on the AMD.

Re:How can this be done? (5, Interesting)

the_weasel (323320) | more than 9 years ago | (#13042976)

Which is exactly what we did when we discovered this. And sure enough, when the Intel compiler thought our AMD was a Genuine Intel certain functions increased dramatically.

The company I work for submitted a few reports on this a few months ago, as I am sure did many others. I am very pleased to see them following up on it.

Re:How can this be done? (3, Informative)

truesaer (135079) | more than 9 years ago | (#13042986)

Its easy to write a compiler that generates working code for a processor (My team of 3 people in a Compilers class wrote an x86 compiler, front to back, in about 8 weeks). It is much much harder to write a compiler that generated good and fast code (now you need hundreds of experienced engineers working for years). Essentially what you do is use really basic and crappy alogorithms for one code path, then use your best optimization algorithms for another path. Now, you just use the crappy path for one processor and the good path for the other, based on the value returned by the CPUID instruction. Viola!


Also, the lawsuit claims that Intel's compiler wont use x86 ISA extensions such as SSE2 even when they're available on AMD processors. There is a reason we have these kinds of ISA extensions, and it is becaue performance is much much better when you use them.

Re:How can this be done? (2, Informative)

morgan_greywolf (835522) | more than 9 years ago | (#13043018)

The compiler optimizes for the Intel by using CPU-specific extensions to the x86 architecture such as SSE, MMX, 64-bit capabilties, etc. The Intel compiler simply fails to detect the capabilities in AMD chips (by not identifying AMD chips as supporting those features, and sticking with generic 386 or 586 code), and thus the result is code that runs slower.

Re:How can this be done? (1, Informative)

Anonymous Coward | more than 9 years ago | (#13043101)

Normally for a particular block of C code the complier only generates one block of machine code. There are places you could generate better optimized machine code but doing so depends on the features exisiting in the CPU that do not exisit in all CPUs. To get around this you and generate both the optimized machine code as well as the generic machine code and place a condition that determines during runtime what code gets executed.

SSE2 (1)

APE992 (676540) | more than 9 years ago | (#13042880)

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.

Apparently they learned from Microsoft... (1)

Linurati (670073) | more than 9 years ago | (#13042886)

Judging by the performance of using Novell Netware shares under Windows compared to a Windows server...

Intel is perpetrating a cover up... (0)

j14ast (258285) | more than 9 years ago | (#13042887)

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.

Re:Intel is perpetrating a cover up... (1)

op12 (830015) | more than 9 years ago | (#13042953)

Fool! My cubicle is covered in tinfoil!

Re:Intel is perpetrating a cover up... (-1)

Anonymous Coward | more than 9 years ago | (#13043025)

Dear god Im at work and have no tinfoil.
Do you have a bathroom? Lock yourself in the bathroom. The metal in the stall walls will give you some protection. And paperclips. Stick a bunch of paperclips in your hair. Use staples if you have to. Hurry, brother!

Never (2, Insightful)

Astroturf_Alert (898937) | more than 9 years ago | (#13042894)

... attribute to malice that which can be fully explained by incompetence.

- some great thinker I'm misquoting

PDF Hell (-1)

Anonymous Coward | more than 9 years ago | (#13042896)

Thanks for the PDF warning...Sheesh!

Old News (0, Troll)

Araxen (561411) | more than 9 years ago | (#13042899)

This was listed in the anti-trust lawsuit and discussed already.

Wow (1, Interesting)

Ryvar (122400) | more than 9 years ago | (#13042903)

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 is semi true (1, Informative)

Anonymous Coward | more than 9 years ago | (#13042997)

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?

Re:It is semi true (1)

Calyth (168525) | more than 9 years ago | (#13043110)

The problem isn't simply knowing how to comile the code paths for maximum performance in Intel, and taking the safe route, but in another thread it has been shown that it would deliberately not use SSE and other features that are available in AMD processors, as part of the agreement that AMD and Intel share some of these things. Why would you think AMD would be allowed to impement SSE and Intel AMD64 extensions?

Re:It is semi true (1)

man_of_mr_e (217855) | more than 9 years ago | (#13043159)

I don't really see how Intel can be responsible for optimizing their compiler to their competition. Lack of optimization (and SSE is an optimization) is not the same thing deliberately torpedoing (which they might be doing as well, but I haven't seen any evidence of that).

I don't see how Intel has any compunction to optimize for non-intel processors, though certainly it would make their compiler better if they did.

Re:It is semi true (0, Troll)

javamann (410973) | more than 9 years ago | (#13043116)

Wow, what color is the sky in your world? You live in a Red state don't you?

So.. wait (1, Interesting)

Anonymous Coward | more than 9 years ago | (#13042905)

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.

Re:So.. wait (2, Informative)

Jonny_eh (765306) | more than 9 years ago | (#13043034)

It doesn't matter what CPU is used for compiling. It happens when the code is executed. The code looks at what CPU it is running on, if it's an Intel, it runs the good code, if it's an AMD, it runs the bad code. At least that's what AMD is claiming.

Re:So.. wait (1)

Anonymous Custard (587661) | more than 9 years ago | (#13043115)

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.


No, the compiler software doesn't care which processor it's running on (though I guess it might if the compiler software was compiled with itself). It's the compiled code - the actual produced software - that does the check and deliberately and needlessly cripples non-Intel processors.

Bastards. (2, Interesting)

luna69 (529007) | more than 9 years ago | (#13042906)

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.

Re:Bastards. (0)

Anonymous Coward | more than 9 years ago | (#13043047)

Why? Why do you claim that Intel can't put whatever they want in their compiler? It's not like anybody is putting a gun to your head to force you to use the Intel compiler, or Intel chips for that matter.

CmdrTaco == automated script (4, Funny)

dame4jc (811440) | more than 9 years ago | (#13042911)

if ($submission) {
$gotaco = "submit";
$spellcheck = "no";
$dupecheck = "definitelynot";
} else {
// I got nothing. *shrugs*
}

Where is all this going (3, Interesting)

1967mustangman (883255) | more than 9 years ago | (#13042912)

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.

Re:Where is all this going (5, Funny)

Rosco P. Coltrane (209368) | more than 9 years ago | (#13043151)

I am huge AMD fan myself

Well, they do require quite a lot of cooling, don't they?

Re:Where is all this going (0)

Anonymous Coward | more than 9 years ago | (#13043154)

I am huge AMD fan myself, but...


Wow, THAT huge?, what core are you cooling exactly??

Wouldn't We Notice It? (3, Insightful)

th1ckasabr1ck (752151) | more than 9 years ago | (#13042914)

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.

If that statement is true, wouldn't there be programs all over that ran fine on Intel but crashed on AMD? Maybe there are and I haven't noticed? Maybe not many people use Intel compilers?

Re:Wouldn't We Notice It? (3, Interesting)

digidave (259925) | more than 9 years ago | (#13043051)

Not to mention the fact that AMD still benchmarks very favorably in games and other CPU-intensive applications, so the slowdown can't be huge.

However, I doubt AMD would claim this if it weren't true. They still have a business to run, unlike SCO, and don't want to damage their reputation.

I suspect that the "crash" part is more conjecture than fact, since the unoptimized code paths might be assumed to be lower quality in many ways. Or perhaps AMD found a single instance of a crash that occurs in one of the unoptimized code paths and even if Intel didn't mean for it to be there, they're still on the hook for that path in the first place.

I have a feeling AMD has been working on this lawsuit for several years, so it will be interesting when they do finally submit the evidence to the court.

Re:Wouldn't We Notice It? (2, Insightful)

Beatbyte (163694) | more than 9 years ago | (#13043076)

They won't crash. They will use slower methods of moving and processing data.

Re:Wouldn't We Notice It? (1)

hackstraw (262471) | more than 9 years ago | (#13043120)

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.

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 don't know if this is true or not. AMD used to feel very comfortable using Intel's compiler to publish their benchmarks to SPEC and whatnot. Maybe they will have to use their own (after they make it).

Now, there is some nonconspiracy theory here. AMD and Intel chips do have different capabilities, and I would assume that Intel's compiler would use, at most, zero of those that are exclusive to AMD and all of the bells and whistles of all of the Intel chips.

Re:Wouldn't We Notice It? (1)

UnknowingFool (672806) | more than 9 years ago | (#13043121)

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?

The programs may not have crashed but just ran slower. The actual performance degradation may not be very noticeable. It may take 6 seconds instead of 5 seconds to do a particular task. It may have also been offset by the processor in certain types of tasks meaning that a "faster" AMD processor performed the same as a "slower" Intel processor so that the benchmarks appear roughly equal. However if the two CPUs were doing millions of tasks like in grid computing, the difference would be more noticeable.

Re:Wouldn't We Notice It? (1)

BRSloth (578824) | more than 9 years ago | (#13043127)

Maybe not many people use Intel compilers?

Or the people using AMD really thought it was a operating system problem. Or even if it was really a processor problem.

Re:Wouldn't We Notice It? (0)

Anonymous Coward | more than 9 years ago | (#13043137)

I think you missed the key word: "or"

In some high percent of the cases, the optimizations likely do not cause crashes but rather performace degrading. So perhaps some in some miniscule case it cases crashes. Still something to be concerned about, but it's a big "or"

Hold on now, Son... (1)

VanWEric (700062) | more than 9 years ago | (#13042917)

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.

Rotten pratice (-1, Offtopic)

Borg453b (746808) | more than 9 years ago | (#13042920)

speaking of amd.. I'm just about to build an Athlon 64 3800 (venice core) based system. I figure the new lines are a bit to pricy. Do any of you have some experiences with that cpu worth mentioning?

It's true--and they know about it (5, Interesting)

Eponymous Cowboy (706996) | more than 9 years ago | (#13042922)

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.

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. ... If the performance of memcpy/memset only are improved for Pentium III will that satisfy you?"

I answered "No," saying that I needed support for AMD processors as well. I also gave them a copy of my own memcpy routine that was 50% faster than theirs--and just used MMX. They closed the support issue and did nothing to resolve it.

I switched back to Visual C++.

Send that to AMD's legal team! (3, Insightful)

Anonymous Custard (587661) | more than 9 years ago | (#13043001)

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

Re:Send that to AMD's legal team! (0)

Anonymous Coward | more than 9 years ago | (#13043095)

I don't mean to jump in, but does 'competition' require that the company in the 'lead' has to help their competitor by seeing whether their software works too? or just say, if its this processor by us do this, else, do it very basically to get it done and not care?

Re:It's true--and they know about it (5, Funny)

Penguin Programmer (241752) | more than 9 years ago | (#13043046)

I switched back to Visual C++.

And when a Microsoft product is the lesser of two evils, you know for sure that there's something fishy going on.

Intel's optimizers assume... (1, Funny)

Anonymous Coward | more than 9 years ago | (#13042925)

...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.

This is not news (2, Informative)

multipart (732754) | more than 9 years ago | (#13042926)

Anyone following the GCC maining lists knows this. It has come up many times there in the past few years.

Tricky.. (1)

mfloy (899187) | more than 9 years ago | (#13042935)

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!

Re:Tricky.. (1)

atari2600 (545988) | more than 9 years ago | (#13042978)

That would be a very very stupid thing to do. An analogy would be "a dog bit me - i am going to bite the bastard dog right back"!

Re:Tricky.. (1)

mfloy (899187) | more than 9 years ago | (#13043109)

If everyone involved had a certain level of class, then yes I agree, but the IT business has become a very cut-throat business. I seriously doubt Intel is the only company crippling competitors, so I think to survive companies need to attack or be attacked. Is it right? Oh course not, but it does seem to be necessary.

Someone's gotta do it (-1, Offtopic)

atari2600 (545988) | more than 9 years ago | (#13042939)

"recient"

You do mean "recent"!

Re:Someone's gotta do it (-1)

Anonymous Coward | more than 9 years ago | (#13043053)

Isn't "recient" a better spelling for the opposite of "ancient"?

I do that ... (5, Funny)

Anonymous Coward | more than 9 years ago | (#13042942)

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!

In other news... (2, Funny)

kryptx (894550) | more than 9 years ago | (#13042943)

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.

libstdc++, Cygwin and GCC = slow (1, Informative)

Anonymous Coward | more than 9 years ago | (#13043087)

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.

Re:In other news... (1)

nagora (177841) | more than 9 years ago | (#13043102)

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.

You might have had a point if that was true.

TWW

Use GNU Compilers! (-1, Flamebait)

tilleyrw (56427) | more than 9 years ago | (#13042971)

Awww... A competitor's compiler is not optimized for our architecture.

Cry me a river.
-- Dogbert

Re:Use GNU Compilers! (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13043146)

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.

And in other news... (2, Funny)

h2d2 (876356) | more than 9 years ago | (#13042973)

...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...)

It's called good business (0, Troll)

Anonymous Coward | more than 9 years ago | (#13042981)

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.

Re:It's called good business (4, Informative)

cens0r (655208) | more than 9 years ago | (#13043073)

That's not what AMD is saying. RTFA. AMD is saying that their chip will run the same binary code produced for the Intel chip. They are saying that Intel deliberately creates substandard code when it detects and AMD chip.

Re:It's called good business (0)

Anonymous Coward | more than 9 years ago | (#13043156)

i know exactly what AMD is saying.

AMD is a business, too. they don't do anything for the good of the people--they do everything for the good of their stockholders.

they see that they can sue INTEL and make them write a compiler optimized for their processors too, cheaper than they can write their own compiler and give it away free (like intel does).

nobody requires anybody to use the INTEL compilier.

btw, who in their right mind would use the INTEL compiler when they're writing programs intended for AMD platforms? that just doesn't make sense.

Instruction timing??? (1, Insightful)

geneing (756949) | more than 9 years ago | (#13042987)

Even if Intel compiler generated the same code independent of the processor, wouldn't code optimized for Intel processor be suboptimal on AMD?

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.

Re:Instruction timing??? (0)

Anonymous Coward | more than 9 years ago | (#13043098)

Did you see the post labeled "It's true--and they know about it" above? He explicitly told the compiler to compile for Pentium 4, and the AMD system ran it no problem, perhaps faster than a Pentium 4 would.

This is old news, however Intel EU raid today... (5, Informative)

Jarnis (266190) | more than 9 years ago | (#13042994)

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 [theinquirer.net]

They probably were hunting for some documents related to alleged antitrust violations - nice free additional ammo for AMD and their case, methinks...

What's surprising about this? (2, Interesting)

stelmach (894192) | more than 9 years ago | (#13043004)

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??

Is this a suprise? Does AMD have a case? (2, Interesting)

cluge (114877) | more than 9 years ago | (#13043006)

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 [slashdot.org] ">
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.

Let me play Devil's Advocate on this.... (2, Insightful)

curmudgeous (710771) | more than 9 years ago | (#13043014)

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.

I think (3, Funny)

bperkins (12056) | more than 9 years ago | (#13043022)

Intel should get the death penalty.

pseudocode (2, Funny)

ohyedoggies (859303) | more than 9 years ago | (#13043024)

if(chip == AMD)
Sleep(80);

Before we damn Intel (1, Troll)

SlayerofGods (682938) | more than 9 years ago | (#13043031)

Isn't it possible they just know their own product better and thus can create a better compiler for it?

Another EXCELLENT reason to use open source.. (5, Insightful)

ylikone (589264) | more than 9 years ago | (#13043032)

...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.

Oh brother (1, Troll)

cheezedawg (413482) | more than 9 years ago | (#13043035)

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.

Write their own compiler then (1, Flamebait)

pbyhre (233979) | more than 9 years ago | (#13043045)

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.

Memmories... (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#13043059)

This post reminds me the time I caught the ferry over to Shelbyville. I needed a new heel for my shoe, so, I decided to go to Morganville, which is what they called Shelbyville in those days. So I tied an onion to my belt, which was the style at the time. Now, to take the ferry cost a nickel, and in those days, nickels had pictures of bumblebees on them. "Give me five bees for a quarter," you'd say.

Now where were we? Oh yeah - the important thing was I had an onion on my belt, which was the style at the time. They didn't have white onions because of the war. The only thing you could get was those big yellow ones...

omg! (2, Interesting)

Stud1y (598856) | more than 9 years ago | (#13043067)

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.

Re:omg! (1)

Stud1y (598856) | more than 9 years ago | (#13043114)

also, on a side note, i am Suing GM because my GM transmission does not bolt up directy to my Ford motor with my Old's manifold... oh, shit, you mean that not all companys have to make their stuff work with other companies? Hmmmmmmmmmmmm.

How Many People Uses the Intel Compiler (0)

Comatose51 (687974) | more than 9 years ago | (#13043072)

How many people uses the Intel compiler compared to other compilers? Did anyone ever suspected this before?

More Likely (3, Interesting)

jmazzi (869663) | more than 9 years ago | (#13043083)

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.

Class Action? (1)

salemlb (857652) | more than 9 years ago | (#13043099)

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.

It wouldn't be optimized for Athlon anyway (1, Insightful)

Len (89493) | more than 9 years ago | (#13043100)

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.

Details (0)

Anonymous Coward | more than 9 years ago | (#13043103)

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.

Extract from PDF bout topic (0)

knuxed (854959) | more than 9 years ago | (#13043112)

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.

Huge binaries? (1)

saterdaies (842986) | more than 9 years ago | (#13043123)

Wouldn't it create huge binaries if it were creating code for Intel and AMD in one executable that were actually differently optimized code?

Is this normal? (1)

Dakrin1 (220684) | more than 9 years ago | (#13043141)

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.

Working with others (1)

thewiz (24994) | more than 9 years ago | (#13043144)

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.

Genuine??? (2, Funny)

Lectoid (891115) | more than 9 years ago | (#13043147)

"If the program detects a "Genuine Intel" microprocessor.... if the program detects an "Authentic AMD" microprocessor..."

Is there some big counterfeit Processor ring I don't know about? What if the program detects a non-genuine Intel/AMD?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>