Prev: No multicore grahics from Intel, Intel withdraws Larrabee!
Next: Several Ntoskrnl BSOD crashes over the last week, but different stopcodes
From: Yousuf Khan on 3 Jan 2010 20:58 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_
From: Robert Myers on 4 Jan 2010 02:14 On Jan 3, 8:58 pm, Yousuf Khan <bbb...(a)yahoo.com> 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_... I will never learn to keep my hands from the keyboard, no matter how unproductive it is to respond to your posts. One of my main reasons for (almost) never buying AMD processors was that I assumed that, protestations from any direction notwithstanding, I would be at a disadvantage using Intel software that I found useful, including icc. Nothing about the agreement between AMD and Intel would be likely to change my mind about that. Intel will undo things that are blatantly sneaky. That's *all* you can count on. That Intel was so arrogant as not to put a disclaimer on its compiler ("This compiler is intended for use with Intel products only.") boggles the imagination. Who knows, maybe they were afraid that such a disclaimer would invite inquiry. In either case, Intel deserves to be burned on this one. But so do the people who were so naive as to buy an Intel compiler without worrying about how it would perform on AMD products. I had always assumed that Intel charged a price for commercial use of its compiler because it didn't want to open source it, and they didn't want to open source it because they didn't want anyone to see what they were really doing (/* Here's where we put the screws to AMD */). That anyone ever would have imagined otherwise leaves me shaking my head. Did AMD know about this for a long time? Of course they did. Did *they* warn their customers? Of course not. It would have cost them a piece of their legal ambush. People who wanted to use AMD products because they were clearly superior for some applications didn't use icc because it wasn't the best compiler for those purposes. 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. Robert. Robert.
From: Yousuf Khan on 4 Jan 2010 19:42 Robert Myers wrote: > But so do the people who were so naive as to buy an Intel compiler > without worrying about how it would perform on AMD products. I had > always assumed that Intel charged a price for commercial use of its > compiler because it didn't want to open source it, and they didn't > want to open source it because they didn't want anyone to see what > they were really doing (/* Here's where we put the screws to AMD */). > That anyone ever would have imagined otherwise leaves me shaking my > head. Did AMD know about this for a long time? Of course they did. > Did *they* warn their customers? Of course not. It would have cost > them a piece of their legal ambush. Your capacity for seeing Intel through rose-colored glasses, and in the meantime blaming the victim never ceases to amaze me. It's AMD's fault for never having warned their customers not to use Intel compilers? If they did, then they would get blamed by the likes of you for whining. But anyways, this is not a new development, it's been known about for years, just like with so much else about the Intel-AMD fight. All of it was at one time considered conspiracy theories. All of it has now been made public and judged by various jurisdictions, and then proven to have been true. > People who wanted to use AMD products because they were clearly > superior for some applications didn't use icc because it wasn't the > best compiler for those purposes. As a matter of fact, Intel used to make a case for why people should be using their compilers, and that they had nothing to worry about when using it on competitor's processors. They used to say that their compilers were a commercial business and as such they assured their compiler customers that due to this, they would ensure their compilers would work just as well in their competitor's processors. > 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. Yousuf Khan
From: Robert Myers on 5 Jan 2010 01:39 On Jan 4, 7:42 pm, Yousuf Khan <bbb...(a)yahoo.com> wrote: > Robert Myers wrote: > > > People who wanted to use AMD products because they were clearly > > superior for some applications didn't use icc because it wasn't the > > best compiler for those purposes. > > As a matter of fact, Intel used to make a case for why people should be > using their compilers, and that they had nothing to worry about when > using it on competitor's processors. They used to say that their > compilers were a commercial business and as such they assured their > compiler customers that due to this, they would ensure their compilers > would work just as well in their competitor's processors. > > > 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. 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. 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. Robert.
From: Bill Davidsen on 5 Jan 2010 15:49
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. 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. 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. |