1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Intel' started by Yousuf Khan, Jan 4, 2010.

  1. Yousuf Khan

    Yousuf Khan Guest

    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_
    Yousuf Khan, Jan 4, 2010
    #1
    1. Advertising

  2. Yousuf Khan

    Robert Myers Guest

    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, Jan 4, 2010
    #2
    1. Advertising

  3. Yousuf Khan

    Yousuf Khan Guest

    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
    Yousuf Khan, Jan 5, 2010
    #3
  4. Yousuf Khan

    Robert Myers Guest

    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.
    Robert Myers, Jan 5, 2010
    #4
  5. 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.
    Bill Davidsen, Jan 5, 2010
    #5
  6. 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
    Steve Thompson, Jan 5, 2010
    #6
  7. 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
    Robert Redelmeier, Jan 6, 2010
    #7
  8. Yousuf Khan

    Yousuf Khan Guest

    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-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
    Yousuf Khan, Jan 7, 2010
    #8
  9. Yousuf Khan

    Yousuf Khan Guest

    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
    Yousuf Khan, Jan 7, 2010
    #9
  10. Yousuf Khan

    Yousuf Khan Guest

    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!

    Yousuf Khan
    Yousuf Khan, Jan 7, 2010
    #10
  11. Yousuf Khan

    shofar Guest

    In article <4b458229$-lp.com>,
    Yousuf Khan <> wrote:

    > 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!
    >


    But, what are the odds that this is actually enforceable?
    What does this mean for the average home user?
    Are only business apps affected?
    Lots of users don't run a lot of heavy-weight apps.
    Say, Nero to burn discs or playing a game from one of many game
    developers. How does a user know if their software was compiled on an
    Intel computer - chances are that a lot of it was.
    Are all the developers going to make newly-compiled versions of their
    old software available for download or snail mail delivery?
    Retroactive how far back - certainly through XP?
    You are right - it will cost Intel billions - if it happens.
    But, somehow, it just doesn't seem realistic with Windows already up to
    7 and loads of new Linux distros freely available.
    Why would the developers spend a lot of time and effort, even if Intel
    pays for it, looking backwards?
    shofar, Jan 7, 2010
    #11
  12. Yousuf Khan

    Robert Myers Guest

    On Jan 7, 1:49 am, 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!


    Keep it up, Yousuf. You're doing a great job of making both you and
    AMD look foolish and vindictive.

    Wouldn't it be great if Microsoft had a competitor like this.

    They could recompense all of us for all of the time we have spent
    trying to deal with their crippled software.

    So Intel made sure its compiler worked for its own processors but
    wasn't so careful with AMD. Like no one else in the business who's in
    a hurry and has limited resources does similar?

    Bottom line, if you had your way: Yousuf happy, lawyers rich, industry
    devastated. Good job.

    Robert.
    Robert Myers, Jan 7, 2010
    #12
  13. Yousuf Khan

    Yousuf Khan Guest

    shofar wrote:
    > In article <4b458229$-lp.com>,
    > Yousuf Khan <> wrote:
    >
    >> 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!
    >>

    >
    > But, what are the odds that this is actually enforceable?


    It's the government, they determine what is enforceable or not.

    > What does this mean for the average home user?


    Probably not much.

    > Are only business apps affected?


    Mostly.

    > Lots of users don't run a lot of heavy-weight apps.
    > Say, Nero to burn discs or playing a game from one of many game
    > developers. How does a user know if their software was compiled on an
    > Intel computer - chances are that a lot of it was.


    The home user doesn't need to know, the company they bought their
    software from, will know what compiler they used to compile with. So if
    Nero was compiled with an Intel compiler, Nero's manufacturer will
    contact Intel, ask for some money back, etc. Most likely whether the
    corrected version gets to the end users is upto the app developer. They
    might advertise it as "New & Improved, now with enhancements for AMD
    processors". :)


    > Are all the developers going to make newly-compiled versions of their
    > old software available for download or snail mail delivery?


    I doubt in most cases that it makes much of a difference to the
    performance of most apps. It's high-performance software that will be
    mostly affected. That's not as big a market as general-purpose
    applications, but it's an important segment.

    > Retroactive how far back - certainly through XP?


    For however long the FTC can prove that there were these shenanigans
    going on. I'm sure it's going to simply mean all versions of the
    compiler going back to version X.Y.Z or something like that.

    > You are right - it will cost Intel billions - if it happens.
    > But, somehow, it just doesn't seem realistic with Windows already up to
    > 7 and loads of new Linux distros freely available.


    Most Linux distros are not done with an Intel compiler, mostly with GNU.
    In the Windows world, most apps are also similarly not done with an
    Intel compiler, mainly a Microsoft one. Intel compilers are known to be
    a niche product compiler.

    > Why would the developers spend a lot of time and effort, even if Intel
    > pays for it, looking backwards?


    They probably won't bother to recompile older versions, but if they have
    new versions of the software in the works, then this may represent a
    very lucrative reduction in their R&D costs. I wouldn't feel too sorry
    for Intel for having to fork over this much cash for other people's
    developments, since it was their fault for purposefully screwing up in
    the first place.

    Yousuf Khan
    Yousuf Khan, Jan 7, 2010
    #13
  14. Yousuf Khan

    Yousuf Khan Guest

    Robert Myers wrote:
    > Keep it up, Yousuf. You're doing a great job of making both you and
    > AMD look foolish and vindictive.


    Keep it up, Robert. You're doing a great job of licking Intel's nether
    regions.

    > Wouldn't it be great if Microsoft had a competitor like this.
    >
    > They could recompense all of us for all of the time we have spent
    > trying to deal with their crippled software.


    Microsoft killed all of their competitors already. It was too late for
    them. Fortunately, Intel got caught early enough. Of course, "early
    enough" in this case, means after only 25 years of having it their own way.

    I can think of at least 5 Intel x86 competitors over the years, all of
    whom are now gone. AMD is the last one left after all of this time.
    Cyrix is gone, NexGen is gone, Transmeta gone, NEC gone, etc.

    > So Intel made sure its compiler worked for its own processors but
    > wasn't so careful with AMD. Like no one else in the business who's in
    > a hurry and has limited resources does similar?


    That's the spin-doctor way of making the truth more palatable. Intel
    wasn't simply "not careful", it was deliberate. In order to detect
    instruction set instructions for processors, Intel's own documentation
    said, all you need to do is detect certain flags in a register which are
    either turned on or turned off depending on whether an instruction set
    is supported or not. Nothing more, nothing less. What Intel did instead
    was detect whether the processor returned, "GenuineIntel" in the CPUID,
    and if it did, then it went to check the flags. You have no need to
    check "GenuineIntel" to look for the instruction set flags.

    > Bottom line, if you had your way: Yousuf happy, lawyers rich, industry
    > devastated. Good job.


    The industry is already a moribund devastated industry ever since Intel
    took up its position as the Mammoth that stands on this ground. PCs have
    not evolved much since the 80's. With the Mammoth moved out of the way,
    new life can take hold now.

    Lawyers will be rich no matter what.

    Yousuf Khan
    Yousuf Khan, Jan 7, 2010
    #14
  15. Yousuf Khan

    Robert Myers Guest

    On Jan 7, 5:29 pm, Yousuf Khan <> wrote:
    > Robert Myers wrote:
    > > Keep it up, Yousuf.  You're doing a great job of making both you and
    > > AMD look foolish and vindictive.

    >
    > Keep it up, Robert. You're doing a great job of licking Intel's nether
    > regions.
    >

    Time to start reporting you for abuse, too? Crude speech is the last
    resort of the desperate.

    > > Wouldn't it be great if Microsoft had a competitor like this.

    >
    > > They could recompense all of us for all of the time we have spent
    > > trying to deal with their crippled software.

    >
    > Microsoft killed all of their competitors already. It was too late for
    > them. Fortunately, Intel got caught early enough. Of course, "early
    > enough" in this case, means after only 25 years of having it their own way.
    >
    > I can think of at least 5 Intel x86 competitors over the years, all of
    > whom are now gone. AMD is the last one left after all of this time.
    > Cyrix is gone, NexGen is gone, Transmeta gone, NEC gone, etc.
    >
    > > So Intel made sure its compiler worked for its own processors but
    > > wasn't so careful with AMD.  Like no one else in the business who's in
    > > a hurry and has limited resources does similar?

    >
    > That's the spin-doctor way of making the truth more palatable. Intel
    > wasn't simply "not careful", it was deliberate. In order to detect
    > instruction set instructions for processors, Intel's own documentation
    > said, all you need to do is detect certain flags in a register which are
    > either turned on or turned off depending on whether an instruction set
    > is supported or not.  Nothing more, nothing less. What Intel did instead
    > was detect whether the processor returned, "GenuineIntel" in the CPUID,
    > and if it did, then it went to check the flags. You have no need to
    > check "GenuineIntel" to look for the instruction set flags.
    >

    Listen. I'm one of the bluntest people on the face of the earth. I
    don't do with BS, not yours, not Intel's, not anybody's. If you want
    to find out how blunt I can be, eventually you will.

    Some weenie at Intel did what was easiest, or some manager at Intel
    told a weenie to do it some way or other. Get a life, Yousuf. There
    was no board meeting about this.

    I'm sick of your finger-pointing. Push hard enough, and I'll
    speculate as to where all this moral certainty comes from, any you
    won't like it one little bit.

    > > Bottom line, if you had your way: Yousuf happy, lawyers rich, industry
    > > devastated. Good job.

    >
    > The industry is already a moribund devastated industry ever since Intel
    > took up its position as the Mammoth that stands on this ground. PCs have
    > not evolved much since the 80's. With the Mammoth moved out of the way,
    > new life can take hold now.
    >

    That's not spin. That's delusion.

    Robert.
    Robert Myers, Jan 7, 2010
    #15
  16. Yousuf Khan

    Robert Myers Guest

    On Jan 7, 1:41 am, Yousuf Khan <> wrote:
    > 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. :)
    >

    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.
    Robert Myers, Jan 7, 2010
    #16
  17. 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.
    Bill Davidsen, Jan 9, 2010
    #17
  18. 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.
    Bill Davidsen, Jan 9, 2010
    #18
  19. * 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
    Benjamin Gawert, Jan 11, 2010
    #19
  20. Yousuf Khan

    Yousuf Khan Guest

    Bill Davidsen wrote:
    > 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.


    Yes, I can see them using that excuse too. The major performance
    enhancing features at question here, such as the SSE instructions are
    not in conflict.

    Anyways, this is not just a matter for the FTC to take up, this is also
    a part of Intel & AMD's private settlement: Intel has agreed to give up
    this practice _from now on_. The FTC however is looking at it from a
    consumer point of view, and it feels it has the right to ask Intel to
    compensate customers who bought Intel's compilers without knowing about
    this in the past.

    > 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.


    It's certainly possible, but AMD used to use flags way outside of
    Intel's flags functions. For example, for Intel-style flags you might
    have had to put $1000 into a register, and for AMD-style flags you would
    have needed to put $8000 into the same register. When checking for Intel
    features on AMD processors, you simply used the Intel values and you got
    back the Intel results.

    As it turns out, now that AMD is responsible for the 64-bit x86
    instructions, Intel now supports the AMD-style flags too. That's because
    a lot of the 64-bit features come from the AMD flags.

    > Vendors in Pentium days (from memory), AMD, Cyrix, Transmeta, SiS, and
    > at least one other. Hope someone remembers this stuff more clearly.


    Those were a bygone era, even before the CPUID was available. In those
    days, you had to use indirect method to figure out which processor you
    were running on, even within the Intel stable. You'd use things like
    self-modifying code to measure the size of instruction prefetch queues
    which might have been different between processor families, etc. I
    remember writing such routines in assembly myself. Once the CPUID
    instruction was introduced this all went away.

    Cyrix made a Pentium-class processor, which didn't support the Pentium
    instruction set instructions. So for all intents and purposes, the Cyrix
    looked just like a really fast 486.

    > In any case, if that claim is true, it's still a very dubious reason to
    > avoid a more thorough check.


    FTC is talking about making Intel license x86 to anybody who wants to
    pay for it. I am figuring that this is the start of a "de jure" rather
    than a "de facto" standards-based x86 instruction set. AMD will have to
    throw in the x64 instructions too.

    So we might actually see x86 processors from Nvidia or others if this
    ruling goes through.

    Yousuf Khan
    Yousuf Khan, Jan 11, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael
    Replies:
    3
    Views:
    1,732
    Janvi
    Aug 9, 2003
  2. Enrico Migliore
    Replies:
    9
    Views:
    326
    Enrico Migliore
    Oct 6, 2003
  3. BillW50
    Replies:
    2
    Views:
    724
    Richard Bonner
    Jun 29, 2010
  4. Aaron
    Replies:
    0
    Views:
    709
    Aaron
    Jun 28, 2010
  5. nithi89
    Replies:
    0
    Views:
    144
    nithi89
    Apr 8, 2013
Loading...

Share This Page