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

Intel's "cripple AMD" function (2009)

agner.org

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Intel's "cripple AMD" function (2009)

#121

Post by mikeash »

corresation wrote: post #117
mikeash wrote: post #116

Earlier quoted context omitted.

Well, your explanation seems completely at odds with what is currently the top-voted comment in this discussion. The linked discussion of the patch he built to fix the problem indicates that the dispatcher does just do CPU feature detection. Here is the URL for reference: http://www.swallowtail.org/naughty-intel.shtml According to that, the code simply does a feature check for SSE, SSE2, and SSE3. Except it also does…

That link doesn't actually show what it does to determine whether to use SSE or SSE2 (much less SSE3 and beyond). That it derives a boolean value is not the same as feature detection. Further the bulk of that entry was from 2004, which is pertinent given that at the time the new Pentium 4 was the first Intel processor with SSE2, and the SSE implementation on the Pentium III was somewhat of a disaster -- both single-p…

Well, here's a complete analysis of the function:

http://publicclu2.blogspot.com/2013/05/analysis-of-intel-com...

Unfortunately, it doesn't show the raw assembly. But in the absence of any information to the contrary, I'm perfectly happy to trust this pseudocode. It shows a bunch of feature checks, preceded by a single "GenuineIntel" check. The code that's gated on "GenuineIntel" would work just fine on non-Intel CPUs. It might sometimes produce sub-optimal results, but overall it'll be fine. There are some CPU family checks, but my understanding is that non-Intel CPUs return the same values that Intel CPUs do for similar architectures/capabilities.

We have multiple people saying that the code runs faster if the "GenuineIntel" checks are removed, we have pseudocode for the function in question that shows a bunch of feature detection with a bit of CPU family detection, neither of which are at all Intel specific. And then we have you, who can't seem to substantiate your claims at all.

If you have actual code or other reasonable evidence to support what you're saying, I'd love to see it. But right now, I'm not buying it.

Re: Intel's "cripple AMD" function (2009)

#122

Post by fzltrp »

mikeash wrote: post #120
fzltrp wrote: post #119

Earlier quoted context omitted.

I understand you. But, is it possible that say, between two features, say SSE 4 and AVX, the less powerfull one happens to be the most efficient for a given algorithm on platform A, and the least efficient on platform B? If yes, how would a the compiler know which path to choose without knowing which platform it is targeting?

It wouldn't, but the sane way to handle that would be to special-case platform A, and let platform B fall back to feature detection, rather than falling back to the worst possible code.

All right, then I suppose that what you are saying is that Intel should leave the genuine Intel chips detection out, and let customers implement specialized paths for AMD products, if the automatically selected path happens to underperform (for a certain performance expectation level), which might be less likely to occur if all the generated paths are available. Did I get this right?

And for people looking to extract every last bit of power from their chips (AMD or not), they might have to implement the path by hand anyway.

> rather than falling back to the worst possible code.

Note that (I think it might have been said elsewhere), it's not the worst possible code, but the least efficient one generated by the compiler (which happens to be quite good already). /pedantic mode

Edit: clarifications.

Re: Intel's "cripple AMD" function (2009)

#123

Post by mikeash »

fzltrp wrote: post #122
mikeash wrote: post #120

Earlier quoted context omitted.

It wouldn't, but the sane way to handle that would be to special-case platform A, and let platform B fall back to feature detection, rather than falling back to the worst possible code.

All right, then I suppose that what you are saying is that Intel should leave the genuine Intel chips detection out, and let customers implement specialized paths for AMD products, if the automatically selected path happens to underperform (for a certain performance expectation level), which might be less likely to occur if all the generated paths are available. Did I get this right? And for people looking to extract…

There are two reasonable choices for Intel to follow:

1. They decide to implement the best possible x86 compiler for all CPU vendors. In this case, they optimize for AMD chips (and anyone else selling x86 chips) just like they currently do for Intel, possibly including AMD-specific code paths.

2. They decide to implement the best possible compiler for Intel x86 CPUs. In this case, they should just ignore the existence of other vendors and do the best they can for their own stuff. If it runs fast on AMD, great. If it doesn't, not their problem.

I'm not sure which of those two what you said falls under, but I think it's one of those. Unfortunately, they have chosen a third path, where not only do they specialize for Intel, but they check for non-Intel and deliberately pessimize performance there.

Re: Intel's "cripple AMD" function (2009)

#124

Post by fzltrp »

mikeash wrote: post #123
fzltrp wrote: post #122

Earlier quoted context omitted.

All right, then I suppose that what you are saying is that Intel should leave the genuine Intel chips detection out, and let customers implement specialized paths for AMD products, if the automatically selected path happens to underperform (for a certain performance expectation level), which might be less likely to occur if all the generated paths are available. Did I get this right? And for people looking to extract…

There are two reasonable choices for Intel to follow: 1. They decide to implement the best possible x86 compiler for all CPU vendors. In this case, they optimize for AMD chips (and anyone else selling x86 chips) just like they currently do for Intel, possibly including AMD-specific code paths. 2. They decide to implement the best possible compiler for Intel x86 CPUs. In this case, they should just ignore the existenc…

2nd choice (sorry for my confused english). But then there might be legal consequences to factor in. Engineers shouldn't probably care about that.

As for the first choice, ideally Intel should do that to provide the best possible compiler out there, but that would really be shooting oneself in the foot, unless they are guaranteed to always have the upper hand on the hardware side. It would also require them to study AMD cpus deeply (how instructions get translated to microcode, how that microcode is optimized, etc) - they probably have people doing that (if that's legal).

Thanks for taking the time to answer me.

Edit: modified my upper comment.

Re: Intel's "cripple AMD" function (2009)

#125

Post by scott_karana »

mikeash wrote: post #110
scott_karana wrote: post #105

Earlier quoted context omitted.

Sure, but why not mandate that everyone tunes the same compiler?...

I'll flip the question around: why mandate it? The class clearly has a performance component, and so students were expected to learn about optimization. Are they going to learn optimization better or worse if you mandate a single compiler? If merely switching compilers is the best path to performance, is that not a valuable lesson? If switching compilers and doing a bunch of extra work to make the code fast with the…

Some compilers aren't generally available. Hypothetically, what if ICC wasn't available freely to educational users, but some of the students had side-jobs where they used it?

You can always mandate a large set of compilers, make them all available, and leave it up to the students to determine which is fastest. I think that acheives both the competitive/educational goal and the level playing field goal.

Re: Intel's "cripple AMD" function (2009)

#126

Post by mikeash »

scott_karana wrote: post #125
mikeash wrote: post #110

Earlier quoted context omitted.

I'll flip the question around: why mandate it? The class clearly has a performance component, and so students were expected to learn about optimization. Are they going to learn optimization better or worse if you mandate a single compiler? If merely switching compilers is the best path to performance, is that not a valuable lesson? If switching compilers and doing a bunch of extra work to make the code fast with the…

Some compilers aren't generally available. Hypothetically, what if ICC wasn't available freely to educational users, but some of the students had side-jobs where they used it? You can always mandate a large set of compilers, make them all available, and leave it up to the students to determine which is fastest. I think that acheives both the competitive/educational goal and the level playing field goal.

I would definitely ban using any compiler that wasn't generally available to the class, or at least disqualify their output from winning the contest. I'd take a generic approach where it's worded just like that, rather than trying to come up with an official set of acceptable compilers, though.

Re: Intel's "cripple AMD" function (2009)

#127

Post by scott_karana »

mikeash wrote: post #126
scott_karana wrote: post #125

Earlier quoted context omitted.

Some compilers aren't generally available. Hypothetically, what if ICC wasn't available freely to educational users, but some of the students had side-jobs where they used it? You can always mandate a large set of compilers, make them all available, and leave it up to the students to determine which is fastest. I think that acheives both the competitive/educational goal and the level playing field goal.

I would definitely ban using any compiler that wasn't generally available to the class, or at least disqualify their output from winning the contest. I'd take a generic approach where it's worded just like that, rather than trying to come up with an official set of acceptable compilers, though.

Sounds fair enough. I suppose we're really on the same page after all. :)

Re: Intel's "cripple AMD" function (2009)

#128

Post by mikeash »

scott_karana wrote: post #127
mikeash wrote: post #126

Earlier quoted context omitted.

I would definitely ban using any compiler that wasn't generally available to the class, or at least disqualify their output from winning the contest. I'd take a generic approach where it's worded just like that, rather than trying to come up with an official set of acceptable compilers, though.

Sounds fair enough. I suppose we're really on the same page after all. :)

Sounds good! Just remember, if the Internet Police show up, this never happened.

Re: Intel's "cripple AMD" function (2009)

#129

Post by coldcode »

fzltrp wrote: post #103
coldcode wrote: post #56

When I worked for a game company we used the Intel compiler for a couple of versions but it caused so many issues for people with AMD we switched back to the MS compiler. In the end the performance difference wasn't enough to matter.

That's interesting: could you elaborate on those problems? I was pretty much supporing Intel on the ground that their competitors products were just running a safe path, but your input might change my view entirely.

It wouldn't be useful anymore, that was 3-4 years ago. At the time besides having AMD issues we had floating point optimization issues which messed up our physics. I doubt it's an issue today.

Re: Intel's "cripple AMD" function (2009)

#130

Post by pconf »

salient wrote: post #33

Intel is one of the least ethical tech companies around. Have they even paid their 1 billion euro fine to the EU Commission yet for trying to force OEMs to not use AMD chips in their products? http://www.engadget.com/2009/05/13/intel-fined-1-45-billion-...

This is one of the reasons I only purchase AMD-based systems. Well that and the fact that AMD's CPU/GMU combo has better graphics performance.

It's either that or support a company whose market advantage is based on anti-competitive practices and who will spend a significant portion of their profits on reducing consumer's choice of CPU (up to the point they no longer have to of course).

Post reply on HN