6 ms·

That analogy worked in 2005, but eight years on the fact that the Intel compiler optimizes primarily for Intel processors is common knowledge, and is explicitly

That analogy worked in 2005, but eight years on the fact that the Intel compiler optimizes primarily for Intel processors is common knowledge, and is explicitly stated by Intel repeatedly on all product materials. Invariably someone will bring up the "but what about benchmarks corrupted by this compiler" conspiracies, without a single example of a benchmark so contrived. It's worth noting that performance and processors isn't as simple as "it has the feature, so use it". Each instructions have timings that vary on different models, and something like SSE(2|3|4) or AVX(2|512) can vary dramatically in its net benefit or detriment by the number of words, alignment, and so on. Many people with the ICC and code that they think will be super fast using it often are surprised to find it hasn't chosen to use them at all, simple setup and teardown eating all possible benefit. In an ideal world we would have an open compilers that made best in class code for all major processors. Sadly that doesn't exist, and even now we have a case where a lot of the complaints about the ICC are "it crippled the code for my AMD....but still made better code than every other compiler".

mikeash 13y ago
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 and with no attention paid to AMD CPUs at all, that would be fine. Nobody would complain. Nobody would expect anything else, really. But that's not what they do: instead, they generate code that checks for an AMD CPU and then deliberately chooses a suboptimal path in that case. So it's not a case of "optimizes primarily for Intel processors", but rather "intentionally cripples performance on non-Intel processors". That is to say, there is a vast gulf between indifference and purposefully making things worse.
- corresation 13y ago
  Your first statement does not follow at all. Do people realize that we're talking very specifically about auto vectorization? This is a very unique, niche area of software (and it is absolutely an optimization, various hysterics notwithstanding), and this notion that various random software you're running are being "crippled" is utterly nonsensical.
  - mikeash 13y ago
    I don't even understand what you're saying here. We seem to be talking past each other, so let me briefly summarize what's going on, since you keep talking about optimizations and how difficult they are, and that just doesn't matter. Intel's compiler produces multiple code paths, each one optimized for different CPU features. The generated code always runs the slowest "fallback" code path on AMD CPUs. Other code paths are still faster than the "fallback" path, even on AMD CPUs, despite not being optimized specifically for them. Thus, Intel is artificially reducing the performance of their generated code on AMD CPUs. They put in more work to make this happen. If they had simply left out the CPU vendor check, AMD CPUs would perform better.
    - corresation 13y ago
      I stated that optimization is hard (each architecture has timings that impact when something is beneficial/when it isn't): Intel baked this into the ICC, but only for Intel targets (for obvious commercial reasons). You say that no, in some anecdote of apparently some anecdotal piece of code on some anecdotal set of data on some anecdotal AMD processor, this was disproven. But that doesn't disprove it in the general whatsoever. If Intel simply generated and ran Intel-targeted code always, we would have the same debate because why didn't they align their instructions and do it in such an order because that would be better on AMD. It is entirely probable that simply running the "Intel" code chain will yield code slower than without on some sets of code with some sets of data, on some AMD architectures. Again, in most cases with vectorization you are not suddenly seeing a magnitude improvement, but rather something that can be marginal in some cases with some cases of data. It is a very hard problem, which is exactly why for all of the bluster the Intel Compiler is still considered the best compiler, 8 years into this controversy. AMD has been contributing to the Open64 compiler for years, but you don't hear much about it. And I'll bet their contributions don't put too much care into Intel processors.
      - nitrogen 13y ago
        1. Old versions of icc ran well on AMD. 2. New icc version adds check for "GenuineIntel". 3. New icc version now runs slowly on AMD.
- fzltrp 13y ago
  > 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 compilers on AMD probably show that aspect), and some very well depend on CPU peculiarities. 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). > they generate code that checks for an AMD CPU Is it really what they do? Are they checking for "GenuineIntel" CPU, or for "AuthenticAMD" ones? There's a slight difference, even if AMD is their only real competitor atm.
  - mikeash 13y ago
    "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.
    - fzltrp 13y ago
      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?
      - mikeash 13y ago
        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.

mikeash 13y ago

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 and with no attention paid to AMD CPUs at all, that would be fine. Nobody would complain. Nobody would expect anything else, really. But that's not what they do: instead, they generate code that checks for an AMD CPU and then deliberately chooses a suboptimal path in that case. So it's not a case of "optimizes primarily for Intel processors", but rather "intentionally cripples performance on non-Intel processors". That is to say, there is a vast gulf between indifference and purposefully making things worse.

corresation 13y ago
Your first statement does not follow at all. Do people realize that we're talking very specifically about auto vectorization? This is a very unique, niche area of software (and it is absolutely an optimization, various hysterics notwithstanding), and this notion that various random software you're running are being "crippled" is utterly nonsensical.
- mikeash 13y ago
  I don't even understand what you're saying here. We seem to be talking past each other, so let me briefly summarize what's going on, since you keep talking about optimizations and how difficult they are, and that just doesn't matter. Intel's compiler produces multiple code paths, each one optimized for different CPU features. The generated code always runs the slowest "fallback" code path on AMD CPUs. Other code paths are still faster than the "fallback" path, even on AMD CPUs, despite not being optimized specifically for them. Thus, Intel is artificially reducing the performance of their generated code on AMD CPUs. They put in more work to make this happen. If they had simply left out the CPU vendor check, AMD CPUs would perform better.
  - corresation 13y ago
    I stated that optimization is hard (each architecture has timings that impact when something is beneficial/when it isn't): Intel baked this into the ICC, but only for Intel targets (for obvious commercial reasons). You say that no, in some anecdote of apparently some anecdotal piece of code on some anecdotal set of data on some anecdotal AMD processor, this was disproven. But that doesn't disprove it in the general whatsoever. If Intel simply generated and ran Intel-targeted code always, we would have the same debate because why didn't they align their instructions and do it in such an order because that would be better on AMD. It is entirely probable that simply running the "Intel" code chain will yield code slower than without on some sets of code with some sets of data, on some AMD architectures. Again, in most cases with vectorization you are not suddenly seeing a magnitude improvement, but rather something that can be marginal in some cases with some cases of data. It is a very hard problem, which is exactly why for all of the bluster the Intel Compiler is still considered the best compiler, 8 years into this controversy. AMD has been contributing to the Open64 compiler for years, but you don't hear much about it. And I'll bet their contributions don't put too much care into Intel processors.
    - nitrogen 13y ago
      1. Old versions of icc ran well on AMD. 2. New icc version adds check for "GenuineIntel". 3. New icc version now runs slowly on AMD.
fzltrp 13y ago
> 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 compilers on AMD probably show that aspect), and some very well depend on CPU peculiarities. 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). > they generate code that checks for an AMD CPU Is it really what they do? Are they checking for "GenuineIntel" CPU, or for "AuthenticAMD" ones? There's a slight difference, even if AMD is their only real competitor atm.
- mikeash 13y ago
  "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.
  - fzltrp 13y ago
    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?
    - mikeash 13y ago
      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.