I personally do not like law suits, but in case a person/organization is involved in recklessness, then a lawasuit is probably the last resort.
On the last point, Intel compilers are known to give the best floating point performance, but I can attest to the fact that it's not the case for AMD processors.
I have a 3700+ running at 237X11 = 2604MHz with SuSe Linux Pro. 9.3 64bit. I'm a premier member of Intel compiler, but this compiler suck really bad on my AMD processor. Let me break it down.
For my test program here are the result.
gcc v 3.3.5(64-bit)
Size of executable 465 KB
Run time 2min 56sec
PathScale v 2.1(64bit)
Size of executable 568 KB
Run time 1min 54sec
Intel Compiler 8.1(64bit)
Size of executable 1343 KB
Run time 5min34sec
As you can see, intel compiler irrespective of any optimization flag, generate a huge executable which is more than the L1+L2 cache combine, so the program has to store part of the executable in the main memory, which is really bad. I have tried other carppy compilers but the highest executable I got was 654 KB.
The question has been asked several time on Intel premier website as to why intel 64-bit compiler generate so huge executable on AMD processors (opteron especially) while those of other competitors provide a reasonable size. The mods on the forum usually ignore it or simply tell you that AMD also uses intel compiler for their SPEC score. That's right, but AMD only uses the 32-bit one, not the 64-bit. They know the 64-bit performance on AMD processor is a real killer, I beleive they are doing something to make the compiler choke and produce so much gabbage once it detects that the CPU is not an intel processor. This is a BAD practice and such attitude does not foster a healthy development. It's a shame that such a big company can resort into such a dirty trick to make itself look better.



Reply With Quote

Bookmarks