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

Comments

Simply ludicrous

[DeadSea]

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

[cwebb1977]

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

Re:Simply ludicrous

[RootsLINUX]

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

[ssyladin]

Neither does Slashdot.

Re:Simply ludicrous

[wo1verin3]

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

We agree.

- darl

Re:Simply ludicrous

[codeguy007]

This won't be hard to prove. Pretty much anyone who wants fast 32Bit code uses the Intel Compilers, even on AMD. However it is a known fact that you need to force the compiler to use optimizations if an Intel Processor is not detected.

Re:Simply ludicrous

[jefe7777]

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.

(that should have been followed by the obligatory:)

oh wait...

Re:Simply ludicrous

[emandres]

I guess it depends on what you're calling "correct" HTML. If you're going by the W3C standard, very, very few sites are up to snuff. I worked as my school's web master for a couple of years, and because I had nothing to do, I decided to bring the code up to W3C XHTML standard.

Wow.

That process of rewriting the code to standards was not only a pain in the butt, but it also broke it on IE. This was one of my many aggravations while working at that job (that and traversing the byzantine bureaucracy (cool... alliteration)). Microsoft goes off on their own weird tangents with IE and throws the standard to the wind, while Firefox sticks with it, but at the same time is choking itself because very few sites out there write to standards.

Re:Simply ludicrous

[team99parody]

If you're too lazy to read the postings here shows such evidence.

It's an example showing the poor assembly-language code when it detects an AMD chip. And notice in that posting that the complier is perfectly capabile of producing efficient AMD code as well. It's sad but funny that the workaround to produce fast code for the AMD chip is to add the string "__intel_cpu_indicator=-512".

Re:Simply ludicrous

[yomahz]

Yes but, they knew enough to block W3C's validator from their site:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .slashdot.org%2F

Re:Simply ludicrous

[RealityMogul]

Define "force the compiler". Is it a command line switch, or something else?

Re:Simply ludicrous

[PhoenixPath]

Yeah...the fab they've been opening up apparently have nothing to do with capacity. Moron. AMD has more then enough capacity. The lawsuit is in an effort to make *use* of that capacity. Apple would have been a drop in thte bucket to AMD, but Apple needs chipsets as well, which is *one* of the reasons they chose Intel. Do some actual research before spewing FUD, okay?

Re:Simply ludicrous

[HunterZ]

No problem, just go through Coral Cache:
http://validator.w3.org/check?uri=http%3A%2F%2Fsla shdot.org.nyud.net%3A8090%2F

Re:Simply ludicrous

[codeguy007]

command line switches to turn on support for various things.

Re:Simply ludicrous

[pixelbeat]

Here's a script to auto gen those options for gcc:
http://www.pixelbeat.org/scripts/gcccpuopt

Re:Simply ludicrous

[10Ghz]

Pretty much anyone who wants fast 32Bit code uses the Intel Compilers, even on AMD

yes, ICC generates faster code even on AMD-CPU's than GCC (for example) does. But that's not the point AMD is making. AMD claims that ICC detects whether the CPU is an AMD-CPU. If it is, it generates slower executables, even though there's no real technical reason to do so. It does so merely to put AMD at a disadvantage. Yes, the code might still be faster than GCC-generated code (you could say that it tells quite a bit about GCC as well....), but it's still crippled when compared to Intel-code.

Re:Simply ludicrous

[iPatch]

A good investigation can be found at http://www.swallowtail.org/naughty-intel.html

Re:Simply ludicrous

[Nogami_Saeko]

It's not so much a matter of making an optimized compiler, it's a matter of a compiler specifically crippling itself if "genuineintel" isn't detected.

What they SHOULD be doing is checking the supported features of the chip and enabling the extensions dynamically as the features are available or not.

To just say "oh, it's not Intel, therefore we'll just use a standard x86 instruction set, no matter what the chip reports it's actually capable of" is the kind of BS that gets companies in hot water. If they want to prove how good their CPU is, then they should be trying to do that as fairly as possible. Playing compiler tricks will only fool people in the shortterm and will catch up with them...

N.

Re:Simply ludicrous

[Anonymous Coward]

I used to work at Intel and when I was there I know they compiled the MSVCRT file in Windows to work better on Intel chips than on AMD chips.

I think the statement was, "If you can't optimize it for Intel, then at least cripple it for AMD", or something to that effect.

I'm sure they do the same thing with their compiler and other things.

Re:Simply ludicrous

[Kazymyr]

So is the issue with the compiler at compile time or at runtime? In other words, is it:

a. compile on an AMD CPU, compiler detects that it runs on an AMD and generates a binary that runs slower on both AMD and Intel CPUs, or...

b. compile anywhere, generated binary checks whether it runs on Intel or AMD and runs slower on AMD?

First one is easy to check for - compile the same source on each of the 2 architectures and compare binaries. If not the same, QED. The second one is sneakier and needs debug/tracing.

How can this be done?

[haluness]

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?

[Roland Piquepaille]

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?

[pcidevel]

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?

[the_weasel]

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?

[truesaer]

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?

[morgan_greywolf]

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?

[thalakan]

Because the Intel compiler actually generates multiple copies of routines, then figures out which one to call at run-time based on a processor detection routine they stick in the program. Example:

[thalakan@shaitan ~]> icc -axKWNPB -c test5.c -o test5.o
test5.c(3) : (col. 16) remark: main has been targeted for automatic cpu dispatch.
[thalakan@shaitan ~]> nm test5.o
00000000 r _2il0floatpacket.1
00000008 r _2il0floatpacket.3
00000020 r _2il0floatpacket.5
00000028 r _2il0floatpacket.7
U __intel_cpu_indicator
U __intel_cpu_indicator_init
U __intel_proc_init
00000000 T main
000000f2 t main.A <-- SSE version
00000028 t main.H <-- x87 version
U printf
U rand
U targets
U time
[thalakan@shaitan ~]>

The remark about automatic CPU dispatch is the compiler notifying you it's going to generate multiple copies of the routine.

Re:How can this be done?

[saigon_from_europe]

And sure enough, when the Intel compiler thought our AMD was a Genuine Intel certain functions increased dramatically.

How did you make it believe it was Intel, not AMD?

My company writes some code that depends on SSE2 instructions. We bought one AMD (64-bit) machine, but code was slower on Athlon64 3200 than on P4 3000 (under WinXP, not on some 64-bit system). We heavily depend on every tact, so I would really like to know how to trick Intel's compiler to believe that AMD is P4.

Re:How can this be done?

[DrSkwid]

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

This assumption is wrong

see here and here

if it wasn't for licensing hiccups the plan9 c compiler would be OpenBSD's default by now :

"I am sorry for the strong minded way in which I am approaching this,
but I am very dissapointed [sic] that after years of requesting that the
plan9 c compiler become free so that we can start extending it and
working with it... that we could be rebuffed in such a way because the
lawyers have not been properly reined in." Theo de Raadt

Re:How can this be done?

[jejones]

Take a look at this page for an example. Also, try here.

Re:How can this be done?

[Rycross]

Maybe you can do what this guy did, if you haven't already seen it.

Re:How can this be done?

[pohl]

Dude, Ken Thompson wrote that compiler. That is the same thing as throwing hundreds of ordinary engineers at the problem.

Never

[Astroturf_Alert]

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

- some great thinker I'm misquoting

Re:Never

[BadMrMojo]

http://en.wikipedia.org/wiki/Hanlon's_razor

Re:Never

[slavemowgli]

They key point here is that in order to invoke Hanlon's razor, you have to be able to *adequately* explain the issue by assuming stupidity instead of malice, though. In other words, the explanation of the issue by means of stupidity must be reasonable; if you (as an unprejudiced, objective person) can instantly dismiss that explanation because it's obviously untrue, then Hanlon's razor does not apply.

Now ask yourself again: do you believe that it's PURE COINCIDENCE that Intel's compiler produces slow code for its competitor's processors? Code that even a novice Assembler programmer would be able to improve instantly (see the rep movsb vs. rep movsd issue mentioned in a comment above, for example?) Do you believe that, for some funny reason, they never happened to notice? That noone ever complained to them about it? That they're really just an innocent victim here?

Well, do you? If yes, please get back to me, I have a used car to sell you. :)

Re:Never

[networkBoy]

I don't know the anser but what about some of the weider ones out there:
IDT Winchip, Cyrix 486/133 and other oddball cpus?

My point is that I don't believe Intel intentionally broke the compiler for AMD, I think they took the approach of supporting their hardware fully, while using the _most compatible_ paths for everyone else. If that is what they did then AMD's argument is worthless. That doesn't change the end result, but it does insulate Intel from any legal wrongdoing.
-nB

Re:Never

[hackstraw]

Now ask yourself again: do you believe that it's PURE COINCIDENCE that Intel's compiler produces slow code for its competitor's processors?

Do you believe that it is pure coincidence that Intel's compiler produces fast code for their processor?

Bastards.

[luna69]

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.

CmdrTaco == automated script

[dame4jc]

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

Re:CmdrTaco == automated script

[Andrewkov]

Hey, don't blame Taco, maybe the Intel perl compiler insterts random spelling errors into text strings!

Where is all this going

[1967mustangman]

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

[Rosco P. Coltrane]

I am huge AMD fan myself

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

Re:Where is all this going

[faraway]

Not for the last few years, in fact AMDs x64 line runs a lot cooler than any Intel processor I've seen.

Re:Where is all this going

[HermanAB]

I wonder how much of that cooler operation is due to the inefficient code? ;-)

Wouldn't We Notice It?

[th1ckasabr1ck]

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?

[digidave]

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?

[Beatbyte]

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

Re:Wouldn't We Notice It?

[man_of_mr_e]

Compiler optimization is a tricky business, and optimizing for one platform can actually slow performance on another.

The story is light on details and doesn't say if the compiler is generating code optmized for the P4 or if it's code supposedly optimized for the AMD or if it was one of those "blended" things. If it's optimized for P4, then I can easily see how intel's instruction ordering can be beneficial for them, and slow the AMD.

Things like pipeline length and differing branch predictors can cause wildly different results on different CPU's.

I really don't see how Intel is under any obligation to optimize their compiler for AMD.

Re:Wouldn't We Notice It?

[Sj0]

WHOAH.

whoah whoah whoah whoah whoah.

Go take a walk and calm the fuck down.

This is a sleazy business tactic, nothing more.

It's true--and they know about it

[Eponymous Cowboy]

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

Re:It's true--and they know about it

[Penguin Programmer]

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.

Re:It's true--and they know about it

[bugnuts]

You forgot this code at the bottom:

push parent, @AMDsubpoena_list

Re:It's true--and they know about it

[WhiteWolf666]

Seriously, if you've still got the documentation, send that to AMD's legal team.

That's a clear instance of them using their monopoly power to damage AMD's reputation with a developer (you).

This *exactly* the sort of evidence they will be using to build their case.

Re:It's true--and they know about it

[bitplayer]

While the focus of these threads is Intel vs. AMD competition, I think that it is worth pointing out that Intel is also crippling (or, at least, "not improving") the performance of their own PIII processors. For what reason would anyone do that, other than an desire to sell more P4 processors when a PIII processor might suffice?

Re:It's true--and they know about it

[justforaday]

Remember how all the benchmarks put the P3 ahead of the P4 (clock for clock) when the P4s debuted? It seems this little trick of theirs could cause developers to say "Wow, the P4 really is fast compared to the P3."

Re:It's true--and they know about it

[springbox]

It's one thing if you don't go out of your way to support an entirely different architecture that you don't make yourself, but it's entirely different to intentionally cripple your program when it finds out it's running on your competitor's hardware that's fully compatible with your own.

Re:It's true--and they know about it

[greed]

Intel is not detecting the supported instruction set, they are detecting the actual CPU.

The way a responsible compiler developer generates code in this situation is to say, "I need feature X, Y and Z for this code path--it will be used if all are present."

The only thing the latest Pentium IVs have on the Athlons is the SSE3 extensions, and that is pretty much irrelevant to most code. "It must be true, Intel told us."

If you switch the Intel compiler so that it does NOT generate multiple-CPU-supporting code, you can generate code that runs on Pentium III, IV, and Athlon just fine. (My overly-cheap ECS Duron board burned out, and who cares about Duron anymore anyway?)

(The magic switches are -xK or -xW, BTW.)

But there is no reason for code targetting a Pentium IV restricted to SSE2 at the highest to NOT run on an Athlon. You can "not support" it, sure, but to DELIBERATELY disable the code when you detect a competitor's chip is... well, anti-competitive.

And this isn't a free compiler. You pay for ICC. (There's a for-free-software download, sure, but most people who really care about this stuff are more than willing to pay, and pay well, for the best compiler optimizations they can get.)

The problem is not that they can't guarantee that the AMD chips work. The problem is they are generating instruction streams that run JUST FINE on AMD chips and their runtime code DISABLES that code path (if you use the recommended or default compiler settings).

It's AMD's job to make sure their implementation of IA32 + whatever extensions is good, not Intel's job to disable code on their chips--except based on the processor capability word. (Whatever "flags" from /proc/cpuinfo is properly called.)

Re:It's true--and they know about it

[jiushao]

I don't see any problem at all with this if it is indeed for all non-intel processors. Targeting a competitor directly by slowing things down is a bad thing, but putting in the simplest default fallback for any other processors than the one you are trying to optimize for seems like a very reasonable way to go. To put it this way; Intel makes a compiler optimized for their products, and they throw in a simple fallback to supply simple code that should work on any basic x86 compatible. If it can be demonstrated that the intent of this is to damage AMD it is a bad thing, but it seems more likely that Intel simply does not care about the performance of the compiler on any other implementation (and seeing how they by no means have a monopoly on compilers there is nothing wrong with that).

Re:It's true--and they know about it

[Jherek Carnelian]

On any non-Intel processors,

I think this is a key fact.

It isn't that ICC generates crummy code for AMD cpus, it generates good code for Intel cpus and crummy code for all others.

AMD would have a much stronger case if they were able to demonstrate that ICC compiled code actively detected AMD cpus and took the slowpath.

Instead, it is reasonable for Intel to argue that the slowpath is a fallback option that is designed for maximum compatibility at the expense of performance. Since they take the same slowpath on ALL unrecognized CPUs (cyrix, transmeta, ???) some, or all, of which may not have been part of Intel's test process -- maximum compatibility is a very reasonable design goal, better than simply refusing to run which is another option.

The end result is the same, but the supporting reasoning behind such a move is likely to prevail in a court of law where, in a dispute like this, motivation makes all the difference.

This is not news

[multipart]

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

Regulators Raid Intel Offices

[dsginter]

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?

Re:Regulators Raid Intel Offices

[Anonymous Coward]

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

Well for starters, Microsoft is still here.

Re:Regulators Raid Intel Offices

[almeida]

Their! I meant their, not there! My apologies to grammar Nazis everywhere.

Re:Regulators Raid Intel Offices

[Anna Merikin]

One might call the dropping of the price of MS's stock from above $120 to $20 within weeks of the judgment a negative result.

Re:Regulators Raid Intel Offices

[Deliveranc3]

But there is another company howling for their blood and ready to replace Intel with a more ethical approach.

AMD will probbaly be sued into oblivion :P

Re:Regulators Raid Intel Offices

[MynockGuano]

Vee vill lhet it pass zis time. Now move along, and don't let it happen again.

Re:Regulators Raid Intel Offices

[rv8]

One might call the dropping of the price of MS's stock from above $120 to $20 within weeks of the judgment a negative result.

And when would this dramatic stock price drop have happened? The data I can find doesn't show this at all. Stock price history. Be sure to consider the effect of stock splits too.

Re:Regulators Raid Intel Offices

[Citizen of Earth]

And when would this dramatic stock price drop have happened?

There was a stock split that took the price from $120 to $60 overnight. The drop to and stagnation at the $25 range for the past few years is not the result of the DOJ ruling, but reflect the fundamentals of Microsoft's stagnating business. Indeed, if the DOJ outcome had any effect, it would be to inflate the MSFT stock price because it demonstrated that the DOJ was impotent to stop Microsoft from further abusing its monopoly position.

Re:Regulators Raid Intel Offices

[Panaflex]

Someone else may feel free to chime in, but it does seem suspicious or, at the least, a conflict of interest that the fines go to the authorities in Europe, while they go to the competitors (treble damages) in the US?

As far as I know, the European laws are designed to protect the Public. Therefor, the "public" - through the form of its government, receives the damages. Correct me if I'm wrong here though.

I do that ...

[Anonymous Coward]

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

[kryptx]

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.

And in other news...

[h2d2]

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

This is old news, however Intel EU raid today...

[Jarnis]

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

Send that to AMD's legal team!

[Anonymous Custard]

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!

[mike260]

I can see where you're coming from, but this isn't just a case of not caring how code performs on your competitors hardware. A byte-by-byte memcpy on x86 is basically insane, and can only be described as willfully crippling non-intel CPUs.

Re:Send that to AMD's legal team!

[irieken]

It is one thing to not help a competitor, but to go out of your way to set them back is unethical. In this case, it appears that Intel programmed its compiler to give a non-Intel chip memcopy instructions that are far below the minimum standard of any chip capable of running current X86 code.

Re:Send that to AMD's legal team!

[Anonymous Custard]

But this altenate code path can run on any x86 chip. Isn't that what compatibility is useful for?

The original code path can run on any x86 chip! Why was an alternate code path even created? Now, if the check said "if thiscpu_mmx_enabled == true, then use fast mmx path, else use slow non-mmx path" then it'd be a legitimate optimization with built in compatibility.

But the compiler doesn't care whether a chip is capable or not, it just cares that it's Intel or not.

Re:Send that to AMD's legal team!

[hackstraw]

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.

If I were Intel, I would respond with the product description of the Intel compiler, as found here http://www.intel.com/cd/software/products/asmo-na/ eng/compilers/clin/index.htm or here http://www.intelcompiler.com/.

The product is clearly labeled as a high performance compiler for Intel CPUs. The grandparent used the wrong tool for the job which required a generic compiler.

Re:Send that to AMD's legal team!

[xenocide2]

The irony being that if you run their "for Intel CPU" code on AMD, you also get performance benefits, implying that perhaps the optimizations are not founded in design but rather business relationships.

Re:Send that to AMD's legal team!

[m50d]

RTFPage you link to. The compiler "exploits the Intel® MMX technology and streaming-SIMD-extensions (SSE/SSE2/SSE3) for IA-32 processors". (My emphasis). IA-32 is the processor architecture, AMD cpus are IA-32. They have the extensions, so the compiler as advertised should produce code that exploits them.

Re:Send that to AMD's legal team!

[Dun Malg]

The product is clearly labeled as a high performance compiler for Intel CPUs. The grandparent used the wrong tool for the job which required a generic compiler.

It would be one thing if the compiler always spit out binaries that ran only on Intel CPUs and errored out when attempting to run on anything else, but it's churning out a multi-path binary that sets up all sorts of unnecessary hurdles for execution on non-Intel CPUs and sends all CPUs not returning a "genuine Intel" ID string down that path. There are already standard methods of determining whether a given CPU is SSE2 instruction compatible, and it's not done by checking the CPU manufacturer. The fig leaf of "ensuring compatibility on unknown hardware" just doesn't cover their actions here.

What's surprising about this?

[stelmach]

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

Re:What's surprising about this?

[99BottlesOfBeerInMyF]

If they intentionally bloated the machine code for AMD processors, then that is wrong.

If you RTFA you'll see that AMD is charging (and numerous sources are confirming) that Intel did extra work to specifically make things slower when programs compiled with their compiler were run on an AMD. On previous poster even posted his two line partial fix for the issue that drastically improved code speed and which he gave to Intel while trying to solve this issue with the compiler. Basically it just tricked the compiler into always using the copy function for Intel processors. This was obviously malicious.

Is this a suprise? Does AMD have a case?

[cluge]

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.

Let me play Devil's Advocate on this....

[curmudgeous]

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

[bperkins]

Intel should get the death penalty.

pseudocode

[ohyedoggies]

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

Another EXCELLENT reason to use open source..

[ylikone]

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

Re:Another EXCELLENT reason to use open source..

[BadDoggie]

You've obviously forgotten (or more likely, never heard of) Ken Thompson. He was the guy that put the self-replicating backdoor in the UNIX compiler which, even if you removed from source, would be re-inserted if the compiler saw that you were compiling kernel or compiler.

He did it to show that the further down you go, the harder it gets to detect such things. So you wrote a new compiler to get around that? Great. How're you planning on compiling it?

Never forget that Open Source is no guarantee of security in and of itself.

woof.

Re:Another EXCELLENT reason to use open source..

[Spy der Mann]

Something like this would never be implemented in an open source compiler. With open source, you know exactly what you get...

If you mean GCC, then, yeah, I couldn't agree more with you. It's equally slow on EVERY processor :)

Re:Another EXCELLENT reason to use open source..

[cristofer8]

http://www.acm.org/classics/sep95/

Read Ken Thompson's classic paper on just that. He makes the case that it would, in fact, be not terribly difficult to hide code that does exactly what intel is being accussed of in an open source compiler, without anyone ever knowing it was there.

Re:Another EXCELLENT reason to use open source..

[Zathrus]

q[With open source, you know exactly what you get.]q

Which, in this case, is really crappy performance.

There's really only one reason to use Intel's compiler -- for performance. It's well known that Intel's compiler generates code that vastly outperforms everything else for the same platform (namely Microsoft Visual C++ 6/7 and gcc -- everyone else (Watcomm, Borland) has long since been relegated to "also ran" status).

We're talking about a rather significant performance difference too -- 20% or more typically. Even more if you compare to gcc (x86 may be one of the most optimized target platforms for gcc/g++, but it's still got a long, long way to go comparatively; even to MSVC).

Intel also has one of the better C++ compliance records as I recall, although MSVC++ 7.0 pretty much eliminated that gap (gcc was far better than MSVC 6, they're roughly equal now), so that's another reason to use them.

But really it's all about the performance. If you have a product targeted for x86 and performance is one of your top criteria, then you'd be foolish to not consider using Intel's compiler for your builds. The reason not everyone does so is because it's expensive and the UI isn't as good as MSVC, particularly for debugging.

All of that said, the allegations are still damning. Yes, Intel has the right to tune the compiler for their CPUs. But if the alternate paths are coded stupidly or intentionally bad-case (worst case is not required) then they could be found to be engaging in anti-competitive behavior. Even if those code paths affect Intel processors as well -- it just has to affect only old Intel processors (hello upgrade!).

Additionally, you might be able to make a (weak) argument that using the "heavily optimized" path only on your own CPUs after having been informed that it works just fine on other CPUs is also anti-competitive. As stated, it's a very weak argument though, since if you do so you'd then have to test any changes you made in that particular heavily optimized code path on the other systems -- which you don't have as much knowledge on.

Of course, the question is why hasn't AMD come out with their own compiler? They should be dedicating resources in this direction instead of (or as well as) litigating Intel. If they don't want to build their own compiler, that's fine -- simply dedicate some time to helping gcc improve its low level compilation performance. I'd be surprised if the gcc x86 team wouldn't welcome any real support of that nature (and by that I mean an employee assigned to actually writing code, or at least a very direct line to AMD engineers that could help an existing gcc coder).

Re:Another EXCELLENT reason to use open source..

[Master of Transhuman]

Uhm, excuse me, but isn't the compiler assembly what is running?

And therefore you can inspect it using a debugger? Or by comparison with the output of an uncompromised compiler that does nearly but not exactly the same compilation methods used by the suspected one?

I think Thompson's point was that while inspecting the source code of the compiler will not reveal if the compiler is compromised, if you have the compiler output, you can still detect it.

This means you can certainly compromise any software if you don't have access to the source code, and if you have the source code, it could be harder. But if you have the output, you can certainly detect the compromise.

One way would be to run the same program through a compiler that is made by someone else which presumably does not use the same method of compromise and compare the output. It would be hard, but no harder I assume than detecting whether copyrighted code is included in some other software.

In fact, this is what Thompson actually said:

"You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of SOURCE-LEVEL [Emphasis added. RSH] verification or scrutiny will protect you from using untrusted code."

He did also say that the lower-level this sort of thing is done on, the harder it is to detect - it would be nearly impossible on the micro-code level. Which seems to support AMD's contention that the Intel modifications could be sabotage, not just conservatism in compiling for non-Intel processors.

In general, of course, while Thompson's point may be valid, it mostly applies to companies or hackers who may have a motivation - and more importantly, a reputation - to do something like this. It would be pointless for someone like GNU to do it. It would get out and it would damage their reputation.

While Thompson said no code other than that written by yourself can be trusted, I hardly think he requires everyone in the world to write their own assemblers, compilers, operating systems and applications (and design their own CPUs to avoid micro-code tampering). Given that, I'd say that open source is still far more likely to be trustworthy than closed-source.

Which renders the entire discussion here moot.

Re:So.. wait

[Jonny_eh]

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.

omg!

[Stud1y]

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:It's called good business

[cens0r]

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.

More Likely

[jmazzi]

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.

Re:Use GNU Compilers!

[Anonymous Coward]

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.

Genuine???

[Lectoid]

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

Who Uses Intel's Compiler?

[justanyone]

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

Apple MP3's? since when?

[AtariAmarok]

" That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. "

Can you find an instance of Apple ever giving MP3's to play in the iPod?

Re:Apple MP3's? since when?

[lp-habu]

Quit being so god damn picky, so it was in AAC not MP3 the point is still valid and accurate nitpicky dumbass moron. Yes flamebait was intentional and it was deserved for the sheer stupidity.

The mistake was yours, not his. Typically it is the one who makes the mistake who can legitimately claim the "stupid" title. Why get so upset? And assuming that you were talking about AAC files, which non-Apple AAC players were made to crash by the free AAC files? I must have missed that.

Relevant Section

[Dakrin1]

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.

Re:Relevant Section

[youknowmewell]

Would this effect 3D graphics rendering or movie encoding/decoding benchmarks? It seems those are the two areas Intel chips still beat AMD chips.

as someone who worked at a compiler company

[MatD]

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.

Re:Write their own compiler then

[Anonymous Coward]

Intel is under no right to make their compiler work efficiently on AMD chips. They can't be expected to spend time on what compiler flags produce the best code on every AMD chip out there. So having it output generic code is the best bet. Of course, if that code is intentionally buggy, that's another issue.

That said, binaries compiled on Intel run just fine on AMDs. Showing that those optimizations at least work on AMD, and AMD's version of IA32 is stable and good.

Write your own compiler? Hell, AMD could dump a few mil on the FSF, and get GCC banged into shape. Someone on the GCC teams should approach them...

Get some more features built into the new GCC 3.x optimization framework. It'd benefit not only AMD support, but everyone else as well, as the back-end would have more optimizations added/tweaked.

Re:The Limit of Lawsuits

[AKAImBatman]

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.

Intel Chip = No Sale

[richyoung]

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.

Compiler + host platform + target platform combo..

[Gopal.V]

> wouldn't there be programs all over that ran fine on Intel but crashed on AMD?

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)

Write Your Own Damn Compiler, AMD!

[tjstork]

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.

Re:Write Your Own Damn Compiler, AMD!

[Anonymous Coward]

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.

Hey, maybe instead AMD could pay people to work on GCC. Oh, wait, they do that already. Why do you think GCC was ported so quickly to AMD64? GCC development is not, AFAIK, funded much (if at all) by the FSF anymore. It's all Apple, AMD, IBM, the various Linux vendors, etc.

I'll take an open source compiler that is installed everywhere over a commercial one that is only on a handful of machines.

Re:The Limit of Lawsuits

[myrick]

AMD does not expect its competitor to support AMD products. AMD's products by nature conform to the same x86 instruction set as Intel's. If Intel's compiler were 'blind' in the sense that it just made x86 code, regardless of the processor, it should run fine. The problem is that Intel is intentionally crippling software that will be run on an AMD system. It doesn't cost Intel anything to 'support' AMD systems; at least, it doesn't require them to expend more money. It does, however, make AMD systems more competitive for Intel to make such a blind compiler, but that's what this whole thing is about, isn't it?

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?

not the same

[Mr. Underbridge]

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.

There's a difference between not supporting hardware and using your position to intentionally tank someone else's product. They have to go out of their way to make code execute crappy on AMD. If they were being chip-agnostic and it just didn't run on AMD, that would be different.

Re:Instruction timing???

[WhiteWolf666]

Yes, and no.

No, if it was using proprietary 'processor specific improvements (TM)'.

However, it is *not*.

The real answer (not Intel's answer), is Yes, because Intel's compiler (which is widely regarded as producing some of the fastest binaries out there) produces code that will only take advantage of standard processor extensions (MMX, SSE, SSE2, SSE3) on 'Genuine Intel' Processors. Regardless of whether or not AMD processors support these extensions, the code excutes in slower, emulation mode if it does not detect 'Genuine Intel'.

When you 'fake' the compiler out by having all processors return 'Genuine Intel', the compiler generates code that will utilize standard extensions that it recognizes (everything but 3DNow, and 3DNow-2), on *any* processor that supports them.

This means your athlon will run SSE code, and your athlon 64 will run SSE,SSE2, and SSE3 code.

Not to mention MMX code, which Intel even disables for non-Pentium 4 Intel processors, even though Intel processors have supported MMX since the Pentium MMX!

This kind of manipulation is clear, and the only purpose is to portray the Pentium 4 as superior, and both older Intel processors and all AMD processors would appear siginificantly faster if the compiler simply utilized whatever extensions where avaliable (on the order of 10-40% for some programs) rather than relying upon the 'Genuine Intel' flag.

Intel *is* a monopoly, and although it is not illegal for a monopoly to exist, monopolies, under current U.S. law, are not permitted to use predatory tactics, especially when going from one market to another (compilers->processors).

Patch for your script

[MattW]

************
*** 5,7 ****
} else {
- // I got nothing. *shrugs*
}
--- 5,7 ---
} else {
+ // I got nothing. Well, except the millions I got paid by Andover. *lights cigar with burning stack of hundreds*
}
************

The story here is the marketing practices...

[asdfasdfasdfasdf]

From TFA:

As a result of Intel's coercion, the HP-AMD desktop
offering was dead on arrival. HP ended up taking only 160,000 of the million microprocessors
AMD offered

• for free.

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.

Re:Oh brother

[Spy der Mann]

Another example of AMD trying to win in the marketplace through whining.

So that means I can cheat in business and whoever sues me is just a whining loser? Cool! Where do I sign up?

Re:The Limit of Lawsuits

[Master of Transhuman]

"Why would AMD expect its competitor, Intel, to write software that supports AMD's own products?"

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 /. to support almost any form of sleazy behavior on the part of some corporation.

Re:The Limit of Lawsuits

[Charles W Griswold]

Part of AMD's claims is outrageous. Why would AMD expect its competitor, Intel, to write software that supports AMD's own products?

The allegation is that Intel writes software that specifically detects AMD chips and then deliberately generates pessimal code that would run poorly on any processor.

This may be bullshit...

[birge]

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.

Re:Instruction timing???

[tomstdenis]

Why are you surprised? AMD has the higher IPC/MIPS design.

Though in this case the solution is simple. Don't buy Intel, don't use ICC. Usually on my P4 I can trick GCC [-fno-regmove comes up] to getting similar performance as ICC v8.

Even then, ICC has good schedulers but performs fewer higher level optimizations. So GCC is usually better in that respect.

Tom

Intel Fortran Compiler works fine for me on AMD

[ajmarchu]

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!

Re:Intel Fortran Compiler works fine for me on AMD

[Dan Berlin]

You don't get it.

The Intel compiler (inlcuding the fortran one) is generating code that looks something like:

if (processor == real intel processor && processor supports SSE/MMX/SSE2/SSE3)
{
Use super optimized code path using MMX/SSE/SSE2/SSE3
}
else
{
Use slower, stupid code path.
}

Instead of
if (processor supports MMX/SSE/SSE2/SSE3)
{
Use super optimized code path using MMX/SSE/SSE2/SSE3
}
else
{
Use slower, stupid code path.
}

They do this *very specfically* to make sure that even though AMD supports the instructions it wants to execute, it won't use the fast path.

This is not some accidental design where it was easier to do this. Intel's marketing folks basically told the compiler folks to do this, or so the story goes.

If you were to patch the check at the beginning of your programs so that it returned true on AMD cpus as well, everything still works fine (in *all* cases), *and* it will run faster on AMD cpus.

Try it. If you look at the posts above, someone has posted the variable you need to reset that it is checking.

Re:Before we damn Intel

[WhiteWolf666]

No;

The Compiler produces MMX, SSE, SSE2, and SSE3 optimized code, but will revert to emulation and pure integer/floating point processing if it does not detect 'Genuine Intel' and 'Pentium 4'.

It's not a question of producing optimal code in terms of processor configuration; that's a gimme. Its a question of not even permitting competitor processors to utilize standard processor extensions, including *older* intel processors that support a partial subset of those features.

Athlon 64s, by the way, support all of these, and operate perfectly, if they are tricked into reporting 'Genuine Intel'.

AMD is not asking Intel to have the compiler produce code that takes advantage of the Athlon architecture; there could be different optimizations because of the Athlon's better memory architecture, or lesser penalty for misprediction, and shorter pipeline.

No, AMD is asking that Intel not produce a compiler that intentional disables standard processor extensions for non-Pentium 4 processors.

Re:The Limit of Lawsuits

[AKAImBatman]

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! ;-)

Re:Oh brother

[tshak]

Intel doesn't come close to a monopoly in the compiler market, so I fail to see what this has to do with the antitrust suit.


That's because you're trivializing the issue. Intel has a chip monopoly their compiler has a huge influence - even if it isn't used in production by the majority of their customers. Purposely reducing the efficiency for AMD chips is a great example of anti-competition, which is what monopoly laws are all about.

Re:Compiler + host platform + target platform comb

[the_weasel]

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.

Work on GCC!

[XanC]

Maybe they will have to use their own [compiler] (after they make it).

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.

Re:The Limit of Lawsuits

[dbrutus]

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.

Re:It is semi true

[drsquare]

In that case, how come when the compiler is tricked into thinking it's running an Intel processor when really it's AMD, the performance increases?

This is obviously nothing to do with the advantages of the processor. The only possible answer is that Intel is deliberately generating poor code for AMD's processors, in order to hamper their competitor. This is inexecusable.

Re:The Limit of Lawsuits

[Waffle Iron]

Why would AMD expect its competitor, Intel, to write software that supports AMD's own products?

As others have pointed out, Intel allegedly went out of their way to secretly hobble code on AMD CPUs. Normally, there would be nothing wrong with pulling a dirty trick like this.

However, this is an *anti trust* case. If you are hold a monopoly position in a market, you are prohibited from taking advantage of that position in various ways, and that may very well include this particular dirty trick.

Re:The Limit of Lawsuits

[InfiniteWisdom]

A single jump instruction, and you have to flush the entire pipeline!
That's patently not true

Sure are alot of people not RTFA'ing.

[digital photo]

Look, the issue is this:

• There are AMD processors that support MMX, SSE, SSE2 (Intel Processor extensions)
• The Intel Compiler is a widely used one for a segment of developers.
• The compiler should create code which will use any and all of Intel's own optimizations( MMX, SSE, SSE2 )
• The compiler will do this for Intel Processors.
• The compiler will not use those very same extensions/optimizations when it detects an AMD cpu.
• Those extensions are implemented by AMD to INTEL's specifications(licensed from them).
• The compiler SHOULD make use of them.
• They are NOT AMD specific extensions/optimizations.
• The allegation is that INTEL made their compiler to work properly when compiling for INTEL chips, but not use ANY optimization extensions(intel or otherwise) when it detects an AMD chip.

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

Re:Sure are alot of people not RTFA'ing.

[SumDog]

I like your argument. You read the article and supported your claims.

For the rest of us...

[Gruneun]

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.

Re:The Limit of Lawsuits

[dubbreak]

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.

Simple Solution: WRITE YOUR OWN COMPILER!!!

[mosel-saar-ruwer]

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

Re:Simple Solution: WRITE YOUR OWN COMPILER!!!

[Chris Burke]

That's just not feasible. Unlike Intel, AMD isn't huge and they don't have a massive software team. However, they aren't stupid and have funded and helped develop compilers. In particular gcc received a lot of help from AMD, especially in developing the AMD64 target.

Re:Simple Solution: WRITE YOUR OWN COMPILER!!!

[Kiryat Malachi]

Nope. Metrowerks was spun off with, and belongs to, Freescale. Which you would know, had you done something so simple as go to their home page and read the words: "Metrowerks - A Freescale Semiconductor Company".

Old news...

[coats]

Within a month after the Opteron release, computer scientists at the Fraunhoffer Institute in Germany had a "perl" script that would modify Intel-compiler generated executables to bypass the "Genuine Intel" test embedded in the executables, and use the optimized code path.

Re:The Limit of Lawsuits

[AKAImBatman]

Hi akaimbatman, we meet again ;)!

(rolls eyes) You again. ;-P

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

Re:The Limit of Lawsuits

[AKAImBatman]

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

*grabs popcorn*

[Glog]

Well, one this is for sure - it will be fun to watch those lawyers explain compiler theory to the jury!

Why? A Better Question....

[EXTomar]

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.

Re:The Limit of Lawsuits

['nother poster]

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.

Re:The Limit of Lawsuits

[mog007]

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.

A workaround for one of the compiler's tricks

[spworley]

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

Metrowerks sold their x86 compiler assets.

[CyricZ]

Metrowerks no longer produces an x86 compiler toolchain:

http://www.metrowerks.com/MW/Develop/Desktop/defau lt.htm

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

Re:Metrowerks sold their x86 compiler assets.

[CyricZ]

I'm interested in who purchased it, especially considering the upcoming transition of Macs to Intel-based systems.

Re:It wouldn't be optimized for Athlon anyway

[Edgewize]

What people seem to be saying is that by patching the binary to force the P4 path, there is a significant performance increase on the Athlon. In other words, even though the P4-optimization is not optimal for the Athlon, it exceeds the performance of the "baseline" path and there is no reason to disable it -- other than to cripple AMD's performance.

Re:The Limit of Lawsuits

[stripes]

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

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.

Re:Compiler + host platform + target platform comb

[Renegrade]

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.

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.

Re: Loop Unrolling

[Lobachevsky]

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.

Re:The Limit of Lawsuits

[Rimbo]

Next up, writing a VI clone in LISP! ;-)

Hello, did someone say "Vi clone in LISP?"

bash$ emacs -nw -f vi-mode

Ya mean, like that? :D

They don't target AMD though...

[Ayanami Rei]

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*

Re:Where's AMD's compiler?

[jtjin]

Hmm, I think the point here is that their compiler is _deliberately_ making inferior executables when it detects an AMD chip.

If the problem was that their compiler will only optimize for an Intel chip, then that is understable and in fact _expected_ from them, but that is not the case here.

Then again, I haven't RTFA so I could be wrong. Here, I'll jump into the stake myself just in case ...

Link

[rangek]

This seems to be it. I haven't tested it yet.

Re:Why? A Better Question....

[Chris Burke]

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.

Do read the complaint!

[PhYrE2k2]

Do read the complaint. The history goes back 25 years in this, and seems to suggest a lot of fowlplay.

12. When IBM defined the original PC standards in the early 1980s, it had available
to it a variety of microprocessors, each with its own instruction set - among these were
microprocessors developed by Motorola, Zilog, National Semiconductor, Fairchild, Intel and
AMD. IBM opted for the Intel architecture, which utilized what became known as the x86
instruction set (after Intel's naming convention for its processors, i.e., 8086, 80186, 80286,
80386), and a compatible operating system offered by Microsoft, known as DOS. Unwilling to
be consigned to a single source of supply, however, IBM demanded that Intel contract with
another integrated circuit company and license it to manufacture x86 chips as a second source.
AMD, which had worked with Intel before in supplying microprocessors, agreed to abandon its
own, competing architecture, and it undertook to manufacture x86 chips as a second source of
supply. Assured that it would not be dependent upon a monopoly supplier of x86 chips, IBM
introduced the PC in August 1981 - and its sales exploded.
13. Although an arbitrator later found that "AMD's sponsorship helped propel Intel
from the chorus line of semiconductor companies into instant stardom," Intel soon set out to
torpedo the 1982 AMD-Intel Technology Exchange Agreement (the "Agreement") by which
each would serve as a second source for products developed by the other. For example, Intel
was required by the Agreement to send AMD timely updates of its second generation 80286
chip. Instead, in a "deliberate[]" effort "to shackle AMD progress," Intel sent AMD
information "deliberately incomplete, deliberately indecipherable and deliberately unusable by
AMD engineers." The conduct was, in the arbitrator's words, "inexcusable and unworthy."
And it was not isolated. Intel elsewhere tried to "sabotage" AMD products, engaged in
"corporate extortion" and demonstrated a near-malevolent determination "to use all of its
economic force and power on a smaller competitor to have its way."
14. In another underhanded effort to stifle AMD's business, Intel decided in 1984 that,
the agreement between the parties notwithstanding, Intel would become the sole-source for the
promising 80386 chip. To fully realize its objective, Intel engaged in an elaborate and
insidious scheme to mislead AMD (and the public) into erroneously believing that AMD would
be a second source, thereby keeping AMD in the Intel "competitive camp" for years. This
duplicitous strategy served a broader purpose than simply preventing AMD from competing
with Intel. Customers' perception that AMD would continue to serve as Intel's authorized
second source was essential to Intel's aim of entrenching the x86 family of microprocessors as
the industry standard (as it had been essential to IBM's original introduction of the PC). Intel
was well aware that if computer manufacturers knew Intel intended to sole source its 32-bit
product, they would be motivated to select alternative products produced by companies
offering second sources. Intel could not preserve the appearance that AMD would second
source the 386 if it terminated the contract or otherwise disclosed its actual intent. Thus, Intel
stalled negotiations over product exchanges, while at the same time allowing AMD to believe
that it could ultimately obtain the 386. This injured competition by deterring and impeding
serious competitive challenges to Intel and directly injured AMD by depriving it of the
revenues and profits it would have earned from such a challenge.
15. Intel implemented this secret plan for the purpose of acquiring and maintaining an
illegal monopoly in the x86 line of microprocessors, which it did by at least 1987.

AMD and GCC

[Michael Meissner]

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.

Another EXCELLENT reason to use cross compilers

[NZheretic]

You've obviously forgotten (or more likely, never heard of) David Mohring.He was the guy that put forward the solution of using many third party C compilers and environments for the original bootstrap compiler build and compare the resulting code after the resulting compiler has rebuild itself for the third time. If the result greatly differs then manual inspect the generated code where it differs.

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.

Re:Intel has NO NEED to ensure compatibility.

[Dun Malg]

Well, then why do they make compiled code work at all on AMD chips?

Because then nobody would use their compiler at all. They wanted to subtly punish buyers of AMD CPUs, not drive away compiler customers.

Re:Let's Clarify this WHOLE DEBATE

[the_greywolf]

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.

according to this guy, it is in fact a boolean test of Intel/non-Intel. correct me if i'm wrong, but AMD is the only competing company to provide an SE2 solution, so i would go as far as to say this is singling them out. the Fortran compiler 7.1 executes a mov $0x1, 0x0 in the case of non-Intel chips, regardless of SSE support. compiler 8.0+ executes SSE instructions in the case of existing SSE support, optimized SSE2 instructions on Intel chips supporting it, and crippled SSE support on non-Intel ships.

if AMD is the only other provider of an SSE2-supporting chip, this could easily be construed as singling-out.

Re:Wow

[LarsG]

If the comments and links I've read are correct, the check is like this:

If (GenuineIntel)
{ supported_extentions = Check_CPU_Capabilities();
Run_optimised_code(supported_extentions);
}
else
{ Run_generic_x86_code(); }

So on any non-Intel CPU, the generic x86 code path will be chosen, but on Intel it will use the best supported (MMX/SSE/etc) code path.

So no specific test for AMD, but at the same time 'willful ignorance' of the x86 extensions supported by non-Intel CPUs. Definately not playing nice, and something that Intel compiler customers certainly are in their right to complain about. But I kind of doubt that it is illegal for Intel to do so, unless there is supporting evidence of Intel going beyond generic x86 in sabotaging AMD CPUs (e.g. generic x86 code especially crafted to run bad on AMD CPUs, smoking gun internal emails etc).

Being an AMD only customer for the last 5 years, I hope AMD has facts to back their claim.

Re:You don't seem to undertand either

[non0score]

Sure. But what other mainstream i386 CPUs are out there that isn't AMD? VIA? Your Verilog implementation of the instruction set on your home PC? If that's the case, then both Cyrix and you should help AMD because they're obviously hating VIA and you too. If that's not the case, then AMD is the only major competitor to Intel, and the statement "looks for non-Intel" is EQUIVALENT to "looks for AMD."

The fact is, it is SUFFICIENT to only test for the presence of SSE/SSE2/SSE3 instruction set. Anything more, like "GENU" "INEI" "NTEL", is absolutely unnecessary. Afterall, why would Intel care if the code fails on non-Intel CPUs if ICC is only meant for Intel CPUs (which it isn't)? On the other hand, if the ICC is designed for other CPUs, then Intel obviously would know (afterall, Intel IS licensing the SSE/SSE2/SSE3 instruction set to AMD) the capabilities of said CPUs, in which case they should enable SSE/SSE2/SSE3 for CPUs capable of the instructions. Last I heard, there weren't any problems with AMD's SSE/SSE2/SSE3 implementation. Therefore, the bottom line is this boils down to a Catch22 situation and Intel should know better than to pull such cheap tricks. If Intel is going to assume that any CPU that implements the i386 instruction set does this without major problems, then why would they not assume the same with SSE/SSE2/SSE3?

Furthermore, if you actually read some of the user posts (and their links http://www.swallowtail.org/naughty-intel.html), you would have realized that ICC deliberately produces segfault code when the execution of the code doesn't find an Intel CPU. According to the article, this is with the -xK flag. That is, it produces ONLY SSE code, and NO fallback to i386 code. Yes, that means this code will fail on the original Pentium. However, in this case, Pentium will still try to execute the SSE code (and subsequently craps out), while AMD CPUs will not (and automatically segfaults). This kinda throws the "and then does 'i386' code path, which is less optimal" argument out the window....

I have no idea why you guys bash AMD

[SwiftWind]

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.