Intel Forced to Remove "Cripple AMD" Function from Compiler?

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/In...om_C ompiler_

On Jan 3, 8:58*pm, 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_...

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.

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

On Jan 4, 7:42*pm, Yousuf Khan 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.

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/In...om_C ompiler_

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.

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

In comp.sys.ibm.pc.hardware.chips Steve Thompson 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

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/In...om_C ompiler_

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)

Robert Myers wrote:
On Jan 4, 7:42 pm, Yousuf Khan 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-programmi...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

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