News for hackers. Stuff that matters.

A comment on Intel's "cripple AMD" function.

Re:Intel's "cripple AMD" function by adame944 on Sunday January 03, 2010 @02:20PM (#1028915)
Bottom line: it's a business decision. Code generated by the Intel compiler "works" on AMD chips, although it may not be optimal. For Intel to support the optimal codepaths on AMD chips would require a substantial amount of research. I don't think they're intentionally crippling AMD chips; just declining to invest the effort to support them optimally.
[ Parent | on HN ]
Re:Intel's "cripple AMD" function by wtallis on Sunday January 03, 2010 @02:33PM (#1028942)
Nope. Checking the vendor string to determine capabilities when the CPUID instruction already has flags for different capabilities is unjustifiable. When a CPU claims SSE2 support, the compiler should enable SSE2, regardless of the vendor string. If AMD's implementation of SSE2 is buggy, that's their problem, and Intel should have no trouble making it into a PR win.

This is really no better than printer manufacturers putting chips into their cartridges so that they can use the DMCA to prevent third parties from refilling or making compatible cartridges.

[ Parent | on HN ]
Re:Intel's "cripple AMD" function by DarkShikari on Sunday January 03, 2010 @02:30PM (#1028936)
That isn't exactly how it works.

The proper way to do it:

    if( CPUIDbits & SSE1_CAPABLE ) {enable SSE1}
    if( CPUIDbits & SSE2_CAPABLE ) {enable SSE2}
    [etc]
The even better way to do it:

    if( CPUIDbits & SSE1_CAPABLE ) {enable SSE1}
    if( CPUIDbits & SSE2_CAPABLE ) {enable SSE2}
    if( CPU is Athlon 64 ) {disable some SSE2 functions}
    if( CPU is Pentium-M ) {disable all SSE2 functions}
    [etc]
Intel's way of doing it:

    if( CPU is Pentium 3 ) {enable SSE1}
    if( CPU is Pentium 4 ) {enable SSE1/SSE2}
    if( CPU is Core 2 ) {enable SSE1/SSE2/SSE3/SSSE3}
    [etc]
Practically all sane applications do things the first way; a couple do things the second way. Anyone doing things the third way is just asking for trouble both in terms of future compatibility and resilience to unexpected situations. For example, some VMs disable certain instruction sets, which would result in SIGILLs when using the last method.
[ Parent | on HN ]
Re:Intel's "cripple AMD" function by kelnos on Monday January 04, 2010 @05:26AM (#1030105)
If you read the article, it looks like Intel's CPU-type dispatcher actually does it the second way (sorta; it appears to only check Intel CPU family IDs), but at the bottom of that list there's a big "if(CPU string is not "GenuineIntel") { disable everything and use crappy fallback code path }".
[ Parent | on HN ]
Re:Intel's "cripple AMD" function by nvoorhies on Sunday January 03, 2010 @02:29PM (#1028932)
In addition to just the question of what path is optimal, they'd have to keep track of all the bugs in AMD's, Cyrix's, Transmeta's, and other implementations which aren't the same as the bugs on Intel x86 chips. Falling back to a subset of the architecture that is more likely to produce the right behavior is the sane thing to do.

e.g. http://www.amd.com/us-en/assets/content_type/white_papers_an... v. http://download.intel.com/design/processor/specupdt/320836.p... - these aren't just a couple gotchas you can put on the back of an index card

[ Parent | on HN ]
Re:Intel's "cripple AMD" function by wtallis on Sunday January 03, 2010 @02:44PM (#1028975)
Have you actually looked at the details of the AMD errata? I scanned through quite a few, and none of them looked at all relevant to whether a compiler should enable certain SIMD extensions. Also, for the bugs that do need workarounds, the fix is typically in the BIOS or kernel, not the compiler.

Regardless of whatever bugs may or may not exist in AMD's chips, it is anti-competitive for Intel's compiler to refuse to enable SSEx extensions on AMD processors that claim compatibility, when the user has requested SSEx instructions to be used, unless Intel has specific knowledge that AMD has never produced a sufficiently bug-free implementation of SSEx.

[ Parent | on HN ]
Re:Intel's "cripple AMD" function by drewcrawford on Sunday January 03, 2010 @04:22PM (#1029164)
I was an AMD intern responsible for writing the software that tests for those bugs (these are my views and not those of AMD).

You're entirely on the mark--the bugs are generally not SSE-related, and are typically worked around at the BIOS level. In addition, these bugs aren't "bugs" in the software sense, but more in the engineering sense; running some specific set of 10 million instructions on 3% of the chips while holding at exactly 28 deg C flips a byte in the L2 cache or something. Not something that's easily reproducible.

OP is also right insofar as there would probably be a few gotchas with weird software that would make some engineer somewhere scratch his head because his for loop returns too quickly every third Monday. That doesn't mean that it's fair for Intel to disable SSEx, but it is probably an accurate observation--AMD and Intel have different bugs.

[ Parent | on HN ]
Re:Intel's "cripple AMD" function by nvoorhies on Sunday January 03, 2010 @04:23PM (#1029168)
Clearly the cost of checking that AMD's errata is accurate is greater than the cost of having icc produce suboptimal code for AMD processors.

The results of incorrect code generation on any given platform would more likely be people ceasing to use Intel's compiler, and that's not something they want to deal with, I'm sure. As to it being anti-competitive, there's nothing stopping AMD from making their own compiler that produces more optimal code and trusts everyone's processors to work as advertised. If it produced better results, people would likely use it.

[ Parent | on HN ]
Re:Intel's "cripple AMD" function by scott_s on Sunday January 03, 2010 @05:17PM (#1029243)
As to it being anti-competitive, there's nothing stopping AMD from making their own compiler that produces more optimal code and trusts everyone's processors to work as advertised.

Sure there is: time and money. Huge companies that are near-monopolies have enormous reservoirs of both in comparison to the competition.

What Intel is accused of doing is considered anti-competitive because they are not actually improving their product. Instead, they are using their stronger market position to degrade the value of another company's product. This harms the overall market, and particularly the consumers. Hence, it's illegal.

[ Parent | on HN ]
Re:Intel's "cripple AMD" function by bensummers on Sunday January 03, 2010 @04:39PM (#1029186)
The objection in the article is not what the compiler does, but how it's advertised. If it was claimed to be an optimizing compiler "for Intel CPUs only", then there would be no problem.

(Of course, if they did that, would people use it?)

[ Parent | on HN ]