Intel compiler deliberately causing slow performance on non-Intel systems

[Mark R]

For quite some time, the Intel compilers have had a reputation for producing highly optimised and very fast code. Many benchmark programs, and scientific programs have been compiled with this important tool.

AMD has alleged that programs created with this tool, are deliberatly modified by the compiler to give poor performance, or simply crash, when run on non-Intel processors. [*]

What investigations, if any, have review sites made into examining performance differences between different platforms, and could this compiler feature be relevant to published benchmarks?


[*] Technical note - several people have thoroughly investigate the behaviour of the Intel compiler. The problem is with SSE/SSE2 handling.

E.g. If code the compiler is set to 'use SSE/SSE2 if available' the program code is modified to look like this:

IF CPUManufacturer <> Intel THEN GOTOnonSSEversion
IF CPUHasSSE2 THEN GOTO SSE2version
IF CPUHasSSE THEN goto SSEversion ELSE GOTO nonSSEversion

or if set to 'only use SSE/SSE2' then the code looks like this

IF CPUManufacturer <> Intel THEN crash
IF CPUHasSSE2 THEN GOTO SSE2version
IF CPUHasSSE THEN goto SSEversion ELSE crash

 

[DaveSimmons]

If true, this is as unethical as when in the old DOS days MS added detect and crash code to thier Windows betas to shut out IBM DOS and DR DOS. With Win95 they then pretended to remove DOS but really just hid it behind a startup logo.

The arrogance of monopolies.

 

[theMan]

yay!

 

[Goi]

Hmmn, I seem to recall seeing reviews/charts that show AMD CPUs actually performing better on programs compiled on the intel compiler than on MS/GCC compilers

 

[Some1ne]

[*] Technical note - several people have thoroughly investigate the behaviour of the Intel compiler. The problem is with SSE/SSE2 handling.

E.g. If code the compiler is set to 'use SSE/SSE2 if available' the program code is modified to look like this:

IF CPUManufacturer <> Intel THEN GOTOnonSSEversion
IF CPUHasSSE2 THEN GOTO SSE2version
IF CPUHasSSE THEN goto SSEversion ELSE GOTO nonSSEversion

or if set to 'only use SSE/SSE2' then the code looks like this

IF CPUManufacturer <> Intel THEN crash
IF CPUHasSSE2 THEN GOTO SSE2version
IF CPUHasSSE THEN goto SSEversion ELSE crash

When I read the brief, when I saw the section alleging that the Intel compiler deliberately made things run poorly/break, my initial reaction was "well, as much as I support AMD, I think they're bending the truth a bit with this one"...but if the above is actually true, then I guess they were correct in their allegation (or maybe the compiler-code in question was simply written before any non-Intel processors supported SSE/SSE2, in which case it would kind of make sense to check and see if it was an Intel CPU). Especially if they really do do 'then crash' instead of simply 'then return 0' or 'then display CPUNotSupportedDialog, return 0'.

 

[glugglug]

This has been known, and there have been 3rd party patches available on the net to eliminate the GenuineIntel check for at least a year and a half now.

 

[Accord99]

If AMD wants a compiler that maximizes their processors' performance, they should make their own. Meanwhile, ICC is still producing very fast code for the K8 family.

http://www.spec.org/cpu2000/results/res2005q2/cpu2000-20050613-04264.html

 

[imported_BikeDude]

Originally posted by: Accord99
If AMD wants a compiler that maximizes their processors' performance, they should make their own. Meanwhile, ICC is still producing very fast code for the K8 family.

Or better yet, cooperate with existing compiler vendors such as Borland.

That said, Intel's behaviour looks like it is motivated by a desire to become a monopoly. To specifically test for brand in the SSE code is just plain bad and irresponsible.

What the market doesn't need is yet another C++ compiler that targets one specific brand of CPUs. Imagine having to ship one executable for Intel and another for AMD. Now tell your users to launch one of them depending on what brand CPU they own... As if the 32->64-bit transition wasn't challenging enough!