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: Robert Myers on 7 Jan 2010 18:58 On Jan 7, 1:41 am, Yousuf Khan <bbb...(a)spammenot.yahoo.com> wrote: > 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. :-) > Human institutions are just that. Human institutions will do what they will do, and what they will do depends a great deal on who you are and where you are. If I were Tim Geithner, I could evade income taxes, play a leading role in one of the worst financial meltdowns in memorty, and go on to be Secretary of the Treasury. If I went most anywhere north of India or slightly to the east or west, I wouldn't want to deal with any of the human institutions there. Human institutions will do what they will do. That what human institutions do has anything at all to do with morality is pure circumstance and perception. Whether I agree with perceptions or not hardly matters, and that you endorse them carries no weight with me. > > 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: > If you don't understand the difference between a civil and a criminal plea, I don't know why I'm wasting my time with you. > Does Intel's compiler cripple AMD performance? - The Tech Reporthttp://techreport.com/discussions.x/8547 > You don't read, do you? When a philosopher was told of Godel's result that there are true theorems that can't be proven (or else you can prove everything), he responded, "Well, who ever would have thought otherwise?" I've told you, and I'm telling you for the last time. Intel compilers do better with Intel processors? Well, who ever would have thought otherwise? Why else would Intel fool around with compilers? > 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. > Too bad the FTC never protected me from anything that matters. > > 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... > When I approached Oracle about software, they tied to encourage me *very strongly* to buy from Dell. Do you think there's the possibility of a connection, and that not all application providers were equally naive? But, now that you mention it, Oracle may be one of AMD's targets here. Not to worry about Microsoft. *They* weren't using Intel compilers. Robert.
From: Jim on 8 Jan 2010 09:56 My 2cents. In ICC 10 (IIRC 9 too) you could require the use of an SSE set so the compiler won't create paths for lower SSE sets (app compiled for SSE3 won't run on a SSE2 CPU). Doing this was faster on my A64x2 instead of letting SSE3 code be optional. Intel took this option out for non-Intel processors in ICC11 though. And I've yet to find an instance where MS's compiler was faster than ICC.
From: Bill Davidsen on 8 Jan 2010 19:08 Jim wrote: > My 2cents. In ICC 10 (IIRC 9 too) you could require the use of an SSE set so > the compiler won't create paths for lower SSE sets (app compiled for SSE3 > won't run on a SSE2 CPU). Doing this was faster on my A64x2 instead of > letting SSE3 code be optional. Intel took this option out for non-Intel > processors in ICC11 though. And I've yet to find an instance where MS's > compiler was faster than ICC. > > I don't normally get any chance to bench ICC against MS, but I do against GCC, and I have to suspect that the code which runs worse on AMD is vector heavy. I don't have any serious apps which I want to use for that, and the integer and non-vector f.p. stuff are close enough to make little difference.
From: Bill Davidsen on 8 Jan 2010 19:23 Yousuf Khan wrote: > 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 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. So what we're talking here is that Intel >> compilers produce better code on Intel CPUs. > > It's a runtime check. It's absolutely required because even on Intel's > own processors, not all instruction set extensions are supported. So > Intel needs to detect which instructions are supported. > > The alternate paths aren't that large in size, but they are critical > paths based on how often they are executed. > >> Interesting to know if the "good" code would actually fail to run >> properly on some AMD CPU, letting Intel claim it was assuring reliable >> operation wherever run. Don't read that to mean I claim that, just >> technical curiosity. > > Intel came up with a system to check for instruction set extensions > which it fails to follow itself! > I read an interesting post on this which said that the logic is this: if the CPU is Intel, the flags are checked, because the meaning of each bit is known. If not, the meaning of some bits as used by other vendors is not identical to Intel usage. Therefore, Intel chose to not use any vector stuff beyond mmx (or sse) rather than try to handle other vendor's use. Clearly you can call this an excuse, and Intel probably could have checked for at least some of the other vendors, assuming that within a vendor the bits are stable. I know there is/was one CPU vendor who used the bits Intel classified as either "unused" or "RFU" to mean something, but I don't remember what. There was code in some program I used which checked that. For modern 32/64 bit CPUs I doubt that's an issue, but I don't really know that everyone uses bits the way Intel does. Vendors in Pentium days (from memory), AMD, Cyrix, Transmeta, SiS, and at least one other. Hope someone remembers this stuff more clearly. In any case, if that claim is true, it's still a very dubious reason to avoid a more thorough check.
From: Benjamin Gawert on 11 Jan 2010 12:41
* Yousuf Khan: > 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! Probably not. The majority of Windows apps is compiled with non-intel compilers, and even less in the Linux world. The intel compilers were common in the HPC field where their performance advantage does matter, but I guess most developers already patched out the relevant part to get full performance on AMD CPUs. Benjamin |