Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel's "cripple AMD" function

agner.org

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Intel's "cripple AMD" function

#21

Post by drewcrawford »

wtallis wrote: post #12
nvoorhies wrote: post #6

Earlier quoted context omitted.

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

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…

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.

Re: Intel's "cripple AMD" function

#22

Post by nvoorhies »

wtallis wrote: post #12
nvoorhies wrote: post #6

Earlier quoted context omitted.

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

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…

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.

Re: Intel's "cripple AMD" function

#23

Post by bensummers »

nvoorhies wrote: post #22
wtallis wrote: post #12

Earlier quoted context omitted.

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…

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 th…

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?)

Re: Intel's "cripple AMD" function

#24

Post by dbz »

jrockway wrote: post #13

Sounds like AMD should just start setting the vendor string to "GenuineIntel", then. (This is something like the "like Mozilla" in every user agent string. If dumb software is going to do dumb tests, and you need to fool the dumb test to get your interoperability.)

That idea is flawed because putting that string will make it optimize for an Intel chip, which will be worse than optimizing for an AMD chip because even though the compiler chooses the worst "optimized" option, it is still optimizing FOR that chip. -> The AMD optimization is optimized -But the Intel optimization is extra optimized (but not optimized for AM- only for itself).

Re: Intel's "cripple AMD" function

#26

Post by scott_s »

Andys wrote: post #25

Sensational headline: this article is only about the Intel C Compiler, which as far as I can see, is only used for benchmarketing and research purposes.

As a systems researcher, I have often used the Intel C Compiler when I wanted to make the most fair comparison possible because it is generally accepted to produce the best code of x86 processors. With that background, I correctly guessed from the headline what the content of the article was.

Re: Intel's "cripple AMD" function

#27

Post by pbhjpbhj »

jrockway wrote: post #13

Sounds like AMD should just start setting the vendor string to "GenuineIntel", then. (This is something like the "like Mozilla" in every user agent string. If dumb software is going to do dumb tests, and you need to fool the dumb test to get your interoperability.)

That would be passing off / trademark infringement FWIW.

Re: Intel's "cripple AMD" function

#28

Post by herf »

When using IPP, I had to rewrite the CPU detector, even for new Intel chips as they came out. This code should be better...really it should just benchmark all the options and catch processor exceptions to pick a supported path.

Instead, the idea is to do a static dispatch for 'known' chips, which is really bad. When the Core2Duo came out, the version of IPP we used reverted to basic MMX code instead of SSE2, about 2.5x slower. This is just bad code, and it's bad on Intel chips, not just AMD.

Also there is the "optimized for benchmarking" piece. It's not always good to use all your cores for one job, for instance, but a lot of these libraries make the assumption that your CPU has nothing else to do.

Re: Intel's "cripple AMD" function

#29

Post by praptak »

Andys wrote: post #25

Sensational headline: this article is only about the Intel C Compiler, which as far as I can see, is only used for benchmarketing and research purposes.

"Only" benchmarketing? If any published benchmarks are affected by this misfeature, it's pitchforks and torches for Intel.

Re: Intel's "cripple AMD" function

#30

Post by scott_s »

nvoorhies wrote: post #22
wtallis wrote: post #12

Earlier quoted context omitted.

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…

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 th…

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.

Post reply on HN