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

111–120 of 131 posts

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

#111

Post by mikeash »

fzltrp wrote: post #106
mikeash wrote: post #52

Earlier quoted context omitted.

People have pointed out that the "Intel" code is faster than the "AMD" code even on AMD chips, so the stuff about performance being difficult to achieve across different CPUs, while true, does not seem to be relevant. All in all, you seem to be downplaying this far more than it deserves. It is not a case that the "compiler optimizes primarily for Intel processors". If it simply produced code built to be good on Intel…

> People have pointed out that the "Intel" code is faster than the "AMD" code even on AMD chips, so the stuff about performance being difficult to achieve across different CPUs, while true, does not seem to be relevant. It is relevant, if you consider that optimization isn't just counting cycles at individual instructions. Some optimization pass may be CPU agnostic (and the difference of performances between compiler…

"Also, if Intel must provide good support for all AMD chips, then they will have to do the same for any other competitor (and there are some iirc)."

Again, nobody in this discussion is saying that Intel must provide good support for all AMD chips. All anyone is saying is that Intel should stop explicitly checking for non-Intel chips and running deliberately slow code on them.

Again, it would be just fine if Intel optimized their compiler exclusively for Intel CPUs and let non-Intel CPUs deal with whatever code they generated. That's what everyone would expect Intel to do. Nobody sane expects Intel to optimize for AMD CPUs in their compiler. We just expect Intel not to put extra effort into crippling them.

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

#112

Post by Peaker »

nathan_long wrote: post #107
fnimick wrote: post #42

Earlier quoted context omitted.

It fixes the legal problem. Intel isn't required to provide an optimized compiler for competitors' chips, but it is required to note that its compiler that is compatible with those chips doesn't optimize code for them. I don't agree either, but it's a perfectly valid solution (and probably the best for Intel's bottom line).

A more effective place to put the notice would be to standard output when you're compiling for AMD.

You're compiling for x86, not AMD. The crippled AMD version is based on a runtime check.

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

#113

Post by Peaker »

sounds wrote: post #74
sitkack wrote: post #66

Earlier quoted context omitted.

When companies do this, they should be fully audited and fined 300% profit, split evenly between the harmed company and the government. If that puts them out of business, so be it.

That would certainly discourage _getting caught_ violating the law. It would also tend to kill off the older companies (weak law of large numbers: if a company violates any of the laws that will kill it, and it exists long enough, it eventually gets caught and killed). It might even lead to some efforts at counter-legislation. For example, companies might lobby to _broaden_ the "get killed" legislation, which would r…

I'd support fines that are proportional to general revenue or profit. A fine must hurt.

Also, an audit and 300% fines would probably not kill companies.

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

#114

Post by corresation »

mikeash wrote: post #108
corresation wrote: post #91

Earlier quoted context omitted.

This, like almost every counter point I've faced thus far, is simply wrong . It is manufactured reality. ICC 8 added auto-vectorization. It, the very first auto-vectorization version, added the "GenuineIntel" branch for such vectorized code, because despite all of the fiction stated otherwise, vectorizing is actually a very hard task (hence why Intel maintains such a lead, and people are still griping about this 9 ye…

I don't understand your "because" statement. Intel added a check for Intel CPUs because vectorization is difficult. That's a complete non sequitur as far as I can tell. It makes as much sense as saying that I baked a chocolate cake because it rained yesterday. Yes, various optimizations, including auto-vectorization, are difficult. Why does that mean Intel had to add a check for Intel CPUs in their compiler?

I'm a glutton for punishment, I suppose.

The Intel compiler makes tight, fast x86[^1]. It ALSO can optionally generate auto-vectorized code paths for specific Intel architectures (it is not simply "has feature versus doesn't have feature", but instead chooses the usage profile of features based on the runtime architecture. Each architecture has significant nuances, setup and teardown costs, etc, and anyone who says "they should just feature sniff" does not understand the factors, though that certainly doesn't stop them from having an opinion), for that small amount of niche code that can be vectorized. Saying that because they don't do the latter for AMD processors means they "crippled" them is nonsensical.

Just to be clear, I have heavily used the Intel compiler for back-office financial applications. I'm not just repeating some opinion I happened across. Nor do I have any particularly love for Intel.

Further, if you understand that Intel specifically targets specific Intel architectures with every branch path, saying "well just run it on all things", again, you simply don't understand the discussion, or the architecture based dispatcher. Yeah, "just run it" might run perfectly fine, and for a contrived example might yield better runtimes, but it also can yield runtime errors or actual performance losses.

As I have repeatedly stated, we should expect great cross architecture and platform (including ARM, which with NEON also has vectorization) compilation with auto-vectorization from the dominant compilers, including GCC, LLVM, and VC. But somehow it always returns to the Intel compiler, nine years after they publicly stated "Yeah, this is for Intel targets".

^1 - So much so that in almost all of these conversations, the people who complain about Intel compilers still use them because it still generates the fastest code for AMD processors, vectorization or not. Which is pretty bizarre, really.

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

#115

Post by neolefty »

fest wrote: post #99

Isn't this crippling a compile-time thing? Is there something in binary that executes best-performing instructions (as opposed to execute just the instructions compiled in) when it's being executed on a specific CPU? If so, how exactly does it work?

It's actually a runtime switch. A compiled x86 binary that uses extra-wide number-crunching instructions (SSE etc) must also work on older processors that don't have those instructions, so it will have two or more code paths. The code paths all perform equivalent computations, but using different instructions.

For example, if you are adding 4 pairs of 64-bit numbers, and there's a special add-4-pairs-of-64-bit-numbers instruction, but it's specified as part of SSE4 (I made that up, but it's the kind of thing that you would find), then you can ask the CPU if it supports SSE4. If it does, then you say great, use this code path that requires SSE4, and we'll do the whole operation in three instructions: load, add, store. Or something.

However, if the CPU says that it doesn't support SSE4, then you'd better have a backup plan. It doesn't have to run as fast, but it should compute the same answer. If it's compiled C code (as opposed to hand-written assembler), the compiler will have you covered. Instead of a single SSE4 instruction, maybe it will take 4 regular 64-bit x86 add instructions instead.

(And if you've written it in assembler, then you probably provided the compiler with a backup C implementation to use if SSE4 isn't supported.)

Intel's compiler is being unfair to AMD CPUs because -- even if they support the instructions that you want -- it won't use them. It will unnecessarily fall back to the plain old non-SSE x86 instructions.

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

#116

Post by mikeash »

corresation wrote: post #114
mikeash wrote: post #108

Earlier quoted context omitted.

I don't understand your "because" statement. Intel added a check for Intel CPUs because vectorization is difficult. That's a complete non sequitur as far as I can tell. It makes as much sense as saying that I baked a chocolate cake because it rained yesterday. Yes, various optimizations, including auto-vectorization, are difficult. Why does that mean Intel had to add a check for Intel CPUs in their compiler?

I'm a glutton for punishment, I suppose. The Intel compiler makes tight, fast x86[^1]. It ALSO can optionally generate auto-vectorized code paths for specific Intel architectures (it is not simply "has feature versus doesn't have feature", but instead chooses the usage profile of features based on the runtime architecture. Each architecture has significant nuances, setup and teardown costs, etc, and anyone who says "…

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 a check for "GenuineIntel" and treats its absence as "no SSE of any kind" even if the CPU otherwise indicates that it does SSE. That check is completely unnecessary and does nothing but slow (or crash!) the code on non-Intel CPUs.

If you still think that's wrong, could you post the relevant code to show it?

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

#117

Post by corresation »

mikeash wrote: post #116
corresation wrote: post #114

Earlier quoted context omitted.

I'm a glutton for punishment, I suppose. The Intel compiler makes tight, fast x86[^1]. It ALSO can optionally generate auto-vectorized code paths for specific Intel architectures (it is not simply "has feature versus doesn't have feature", but instead chooses the usage profile of features based on the runtime architecture. Each architecture has significant nuances, setup and teardown costs, etc, and anyone who says "…

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-precision width (it simulated 128-bits through two 64-bit operations, and for the P3 compilers could optimize for its specific handicap), and sharing resources with the floating point unit. So the feature flag, coupled with "GenuineIntel", was all they needed to know for the two possible Intel variants with support.

Since then the dispatcher and options have grown dramatically more complex as the number of architectures and permutations have exploded.

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

#118

Post by wglb »

corresation wrote: post #104
wglb wrote: post #86

Earlier quoted context omitted.

Have you ever seen benchmarks to suggest that Intel is not the market leader in compilers is actually true?

That comment was in relation to market share, not performance. Few would argue that Intel has more than a low single-digit percentage market share of the overall compiler market. People should be far, far more concerned about how GCC, llvm and Visual Studio do in vectorizing code to SSE/AVX.

So if we were to define "market" as "compilers that people pay money for", would Intel be market leader then? (Certainly not a common definition, I agree.)

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

#119

Post by fzltrp »

mikeash wrote: post #111
fzltrp wrote: post #106

Earlier quoted context omitted.

> People have pointed out that the "Intel" code is faster than the "AMD" code even on AMD chips, so the stuff about performance being difficult to achieve across different CPUs, while true, does not seem to be relevant. It is relevant, if you consider that optimization isn't just counting cycles at individual instructions. Some optimization pass may be CPU agnostic (and the difference of performances between compiler…

"Also, if Intel must provide good support for all AMD chips, then they will have to do the same for any other competitor (and there are some iirc)." Again, nobody in this discussion is saying that Intel must provide good support for all AMD chips. All anyone is saying is that Intel should stop explicitly checking for non-Intel chips and running deliberately slow code on them. Again, it would be just fine if Intel opt…

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?

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

#120

Post by mikeash »

fzltrp wrote: post #119
mikeash wrote: post #111

Earlier quoted context omitted.

"Also, if Intel must provide good support for all AMD chips, then they will have to do the same for any other competitor (and there are some iirc)." Again, nobody in this discussion is saying that Intel must provide good support for all AMD chips. All anyone is saying is that Intel should stop explicitly checking for non-Intel chips and running deliberately slow code on them. Again, it would be just fine if Intel opt…

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.
Post reply on HN