Intel Forced to Remove "Cripple AMD" Function from Compiler?
in [Chips]
|
Prev: No multicore grahics from Intel, Intel withdraws Larrabee!
Next: Several Ntoskrnl BSOD crashes over the last week, but different stopcodes
From: Steve Thompson on 5 Jan 2010 16:05 On Tue, 5 Jan 2010, Bill Davidsen wrote: > I assume that the ID string check takes place at compile time, and that > running the compiler on a Intel CPU would produce the optimal code run > anywhere. We have Fortran code that does not run on boxes with AMD processors, even when compiled on boxes with Intel processors (using ifort). And we have code that does work in the same situation. What triggers the difference I do not know. Steve
From: Robert Redelmeier on 6 Jan 2010 10:10 In comp.sys.ibm.pc.hardware.chips Steve Thompson <smt(a)vgersoft.com> wrote in part: > On Tue, 5 Jan 2010, Bill Davidsen wrote: >> I assume that the ID string check takes place at compile time, >> and that running the compiler on a Intel CPU would produce the >> optimal code run anywhere. I rather assume the check is at runtime since binaries are so widely distributed in the MS-Windows world. The check would occur at startup and map in differently optimized libraries for things like memcpy() and DOT_PRODUCT() > We have Fortran code that does not run on boxes with AMD > processors, even when compiled on boxes with Intel processors > (using ifort). And we have code that does work in the same > situation. What triggers the difference I do not know. Nasty. I would hope after the Intel F00F bug that all FPUs produce "correct" results. However, floats are tricky ("God created the integers, all else is the work of man.") Order of operations definitely matters and so do register spills from 80bits to doubles when calculations are "sensitive" like with matrix determinants close to zero. XMM/SSE2 may run fast but can produce different results from x87. -- Robert R
From: Sebastian Kaliszewski on 6 Jan 2010 13:23 Bill Davidsen wrote: > Yousuf Khan wrote: >> Intel Forced to Remove "Cripple AMD" Function from Compiler? >> "In fact, Fog points out that even benchmarking programs are affected >> by this, up to a point where benchmark results can differ greatly >> depending on how a processor identifies itself. Ars found out that by >> changing the CPUID of a VIA Nano processor to AuthenticAMD you could >> increase performance in PCMark 2005's memory subsystem test by 10% - >> changing it to GenuineIntel yields a 47.4% performance improvement! >> There's more on that here [print version - the regular one won't load >> for me]. " >> http://www.osnews.com/story/22683/Intel_Forced_to_Remove_Cripple_AMD_Function_from_Compiler_ >> > I assume that the ID string check takes place at compile time, and that > running the compiler on a Intel CPU would produce the optimal code run > anywhere. Yet, your assumption is wrong. > I find it hard to believe that they have two or more sets of > code in the object file and incur the overhead of a runtime check and > selection, just because the executable would be huge and slow on any > CPU. Executable is somewhat larger (and not many times as large part of the code is the same). And One-time check at the application startup does not matter at all as i takes about 1us. > So what we're talking here is that Intel compilers produce better > code on Intel CPUs. Nope. Intel compilers produce the same code on Intel and non Intel CPUs. And that code runs worse on non-Intel CPUs. rgds Sebastian Kaliszewski -- "Never underestimate the power of human stupidity" -- L. Lang -- http://www.tajga.org -- (some photos from my travels)
From: Yousuf Khan on 7 Jan 2010 01:41 Robert Myers wrote: > On Jan 4, 7:42 pm, Yousuf Khan <bbb...(a)yahoo.com> wrote: >> Robert Myers wrote: >>> I'm sure that you'll come back with all kinds of moralistic bluster. >>> That's the price I pay for responding to your posts. >> Sure, if you want to call legal-findings to be moralistic bluster, then >> go right ahead. >> > > As soon as the regulatory authorities present their credentials as > God, then I will be interested in their moral opinions. Until then, > they are just another political institution, so far as I'm concerned. Ah, I see, only God is worthy to judge Intel now. Intel is beyond the realm of mere mortal institutions such as courts and governments. :-) > If Intel deliberately and blatantly misled customers into believing > that they should buy and use Intel compilers for AMD processors, > knowing full well that the compiler is crippled for said processors, > that's potentially criminal commercial fraud. I don't know that any > such thing has been proven. That's "potentially criminal commercial fraud", you think? Has it been proven in court? You bet it has, as I said this is not a new accusation, and you can be sure that the EU which has already ruled against Intel has found it guilty on that point too. AMD had already included the accusation in its original 2005 civil anti-trust filing against Intel. That filing pre-dated the EU ruling. Here's an article from 2005: Does Intel's compiler cripple AMD performance? - The Tech Report http://techreport.com/discussions.x/8547 Are your Intel rose-tinted glasses finally starting to get a little scratchy, now that software integrity is involved? The FTC is ready to make Intel pay compensation to software developers which used Intel's compilers for recompiling and redistributing all of their software. > From my experience, icc does enough better than gcc that it is worth > using it, but it doesn't do wildly better in most cases. Either the > compiler wasn't all that crippled, or it did even worse than gcc. If > someone didn't even bother to test whether icc was worth the bother > relative to gcc, then I hardly know what to say. At that, it was > widely known that icc was not the best compiler for AMD processors. > > If I wanted to compile for Windows and not for Linux, I'd be using a > compiler from Microsoft. Before I even *considered* an Intel > compiler, I'd test it against a compiler from Microsoft. You seem to > live in a world where ordinary common sense is suspended. Oracle has been using Intel compilers since 2003. Intel programming tools edge forward - CNET News "Database giant Oracle has chosen Intel to supply crucial programming tools called compilers for creating software that runs on servers using Intel processors. The move is one of several steps Intel is taking to improve the software's utility. " http://news.cnet.com/Intel-programming-tools-edge-forward/2100-1007_3-1000311.html And as I said, FTC is going to make Intel pay to recompile and redistribute all of the software created on Intel compilers. That includes all of that Oracle software. That should cost Intel billions, just by itself! Yousuf Khan
From: Yousuf Khan on 7 Jan 2010 01:43
Steve Thompson wrote: > On Tue, 5 Jan 2010, Bill Davidsen wrote: > >> I assume that the ID string check takes place at compile time, and >> that running the compiler on a Intel CPU would produce the optimal >> code run anywhere. > > We have Fortran code that does not run on boxes with AMD processors, > even when compiled on boxes with Intel processors (using ifort). And we > have code that does work in the same situation. What triggers the > difference I do not know. Perhaps it's this? Does Intel's compiler cripple AMD performance? - The Tech Report "A gent named Mark Mackey has spent some time with Intel's Fortran compiler for Linux, and his experiences would seem to back up AMD's claims. (Thanks to Per Olofsson for the link.) After a bit of testing and looking into Intel's CPU identification routine, he comes to this realization: The code produced by the Intel compiler checks to see if it's running on an Intel chip. If not, it deliberately won't run SSE or SSE2 code, even if the chip capability flags (avaialble [sic] through the 'cpuid' instruction) say that it can. In other words, the code has been nobbled to run slower on non-Intel chips. " http://techreport.com/discussions.x/8547 Yousuf Khan |