9 ms·

That's some seriously scummy stuff from Intel.

dekken_ 7y ago
related https://www.youtube.com/watch?v=eINDw7zH5dk https://www.youtube.com/watch?v=eINDw7zH5dk
faeyanpiraat 7y ago
Maybe, but please note this part of the article: "It is also possible that the resulting code path has some precision loss or other problems on AMD hardware. I have not tested for that!"
- RL_Quine 7y ago
  I'm a lot more willing to believe that Intel is attempting to cook benchmarks, than it being a decision made out of caution to save face for AMD if the results are incorrect. They sat for an excruciatingly long time making no obvious improvements to their processors, and then suddenly more than halved the price of everything the moment there was competition.
  - catalogia 7y ago
    Yeah, some companies might deserve the benefit of the doubt but Intel isn't one of them. They shouldn't be judged in a vacuum; Intel is a company with a long and nasty history of underhanded bullshit.
  - creato 7y ago
    > than it being a decision made out of caution to save face for AMD if the results are incorrect. It's not about "saving face" for anyone, it's about the possibility of bug reports that need to be investigated, and possibly new code paths need to be added if a fix is necessary. > and then suddenly more than halved the price of everything the moment there was competition. This would have happened regardless of how much or little their products improved in the prior years. The price is what enough people are willing to pay, and that goes down if there's an alternative.
    - Maxious 7y ago
      eg. "AMD shipped Ryzen 3000 with a serious microcode bug in its random number generator." "Windows users couldn't successfully launch Destiny 2, and Linux users in many cases couldn't even get their system to boot." https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/ https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd...
      - djmips 7y ago
        The article currently states the Destiny 2 issue was unrelated to the bug in the random number generator.
creato 7y ago
See the caveat at the end: > It is also possible that the resulting code path has some precision loss or other problems on AMD hardware. I have not tested for that! Intel doesn't test it either, which is why they disable it. You could argue that they should test and enable on AMD CPUs, but this isn't clearly scummy behavior (to me), it's not a zero cost decision they made solely to screw over AMD. Buying the hardware and testing it has a cost. It may not even be possible to test it to the same degree they test their own hardware. There may be modes, subtle differences between architecture versions, etc. that are hard to know about to test for.
- nemetroid 7y ago
  Until the opposite has been shown, the assumption should be that a CPU that indicates that it supports AVX2 does support AVX2.
  - roenxi 7y ago
    That is not the case, this is at the boundary of software and hardware and real-world concerns dominate. It is quite possible that a library highly optimised to a specific hardware set could have ghastly bugs on hardware it isn't tested on and testing has a cost. Intel is being reasonable and in a sense prudent by only supporting hardware they understand very well. It isn't like they are sending the lawyers out to sue anyone writing high performance code on AMD chips - that would be unreasonable.
    - the8472 7y ago
      The usual approach (e.g. taken in the linux kernel, llvm, hotspot jvm) is to look at the cpuid capability flags and rely on them by default and only blacklist specific CPU models when they don't implement advertised features correctly, not the other way around.
    - yxhuvud 7y ago
      Then don't test it. It is perfectly ok (and even expected) for Intel to not test on AMD. Just don't intentionally cripple it.
jandrewrogers 7y ago
The caveat at the end of the article is grounded in reality. I've personally experienced material precision bugs when running Intel-targeted code on AMD microarchitectures. These edge cases are very difficult to test for. The only reason we ever detected instances of these bugs is because we ran numerical codes at massive scales (finding the edge cases by brute force) and customers occasionally ran identical test workloads across both Intel and AMD clusters and compared numerical results. Every so often, something would surface. It is not Intel's responsibility to ensure that there is no obscure edge case in AMD's microarchitecture that may cause the MKL algorithms to give incorrect results on AMD silicon. MKL's design is based in part on Intel knowing the internal details of their own silicon.
- Dylan16807 7y ago
  Correct, it's not their responsibility to avoid AMD bugs. So if switching from fast possibly-buggy instructions to slow possibly-buggy instructions is some lazy attempt at avoiding bugs, they should stop doing it.
- jchw 7y ago
  > MKL's design is based in part on Intel knowing the internal details of their own silicon. This is just conjecture unless there’s a citation to support it. Besides, the microarchitecture design is bound to change dramatically over time just as a matter of course. Relying on things that they don’t document publicly is probably not a wise strategy. How would the teams coordinate not breaking each-other? I can imagine such a position would be incredibly unpopular amongst those working on silicon designs (and maybe not popular amongst those working on software, either.) Also, nobody has really presented a reasoning that justifies this behavior, since if it broke on AMD hardware, it still wouldn’t be Intel’s problem, and therefore perhaps they should just use the instruction sets as intended and documented instead.
  - jandrewrogers 7y ago
    This is literally discussed in the MKL documentation, which spends considerable time on numerical reproducibility across microarchitectures. You have a rather strong opinion for someone who can't be bothered to educate themselves on the subject matter. I'm not an Intel fanboi but casually dismissing this specific issue is just ignorance. Intel's algorithms, for better and worse, are very aware of the limitations of their silicon implementations.
deleted 7y ago
[deleted]
zepearl 7y ago
Is the "MKL" mentioned by the article referring to https://docs.anaconda.com/mkl-optimizations/ https://docs.anaconda.com/mkl-optimizations/ (or something similar)? If yes, then there is apparently an active engagement by Intel (therefore involving people&money) and I don't see anything wrong if they optimize their code for their CPUs and then ignore other manufacturers (AMD) - mooost probably they just don't have a reason about why they should improve their competition + trying to do that anyway (without having full insight about the "foreign" multiple CPU architectures) might generate even worse performance which in turn would backfire (e.g. "aaahh Intel is sabotaging AMD CPUs"). So, personally I would have no problem if when using iMKL ("intel MKL") the code would run faster on Intel CPUs by default and being conservative on other CPUs - but if I would own an AMD CPU then I would expect AMD to implement some similar optimization for their own CPUs (aMKL?).
- gameswithgo 7y ago
  what you are talking about isn’t the situation. they are intentionally detecting cpu features wrong so as to not use features amd cpus have. nobody is expecting special amd optimization attention.
  - zepearl 7y ago
    Ok, if it's like that ("intentionally detecting cpu features wrong") then I would agree. Can a "CPU feature" (e.g. sse2, avx, aes, etc...) be implemented the same way between different architectures?
    - gallexme 7y ago
      (Until someone has a more detailed answer) Both Intel and AMD are on the same X86 architecture, and sse2 etc are just extensions of the X86 architecture, u can check which feature flags a CPU has And the call/use of these features is the same for AMD or Intel
      - BeeOnRope 7y ago
        They explicitly look for the "GenuineIntel" product string and then basically disable all the efficient code paths if it isn't found, totally against their own advice for ISA extension detection [1]. https://www.agner.org/optimize/blog/read.php?i=49 https://www.agner.org/optimize/blog/read.php?i=49

related https://www.youtube.com/watch?v=eINDw7zH5dk https://www.youtube.com/watch?v=eINDw7zH5dk

Maybe, but please note this part of the article: "It is also possible that the resulting code path has some precision loss or other problems on AMD hardware. I have not tested for that!"

RL_Quine 7y ago
I'm a lot more willing to believe that Intel is attempting to cook benchmarks, than it being a decision made out of caution to save face for AMD if the results are incorrect. They sat for an excruciatingly long time making no obvious improvements to their processors, and then suddenly more than halved the price of everything the moment there was competition.
- catalogia 7y ago
  Yeah, some companies might deserve the benefit of the doubt but Intel isn't one of them. They shouldn't be judged in a vacuum; Intel is a company with a long and nasty history of underhanded bullshit.
- creato 7y ago
  > than it being a decision made out of caution to save face for AMD if the results are incorrect. It's not about "saving face" for anyone, it's about the possibility of bug reports that need to be investigated, and possibly new code paths need to be added if a fix is necessary. > and then suddenly more than halved the price of everything the moment there was competition. This would have happened regardless of how much or little their products improved in the prior years. The price is what enough people are willing to pay, and that goes down if there's an alternative.
  - Maxious 7y ago
    eg. "AMD shipped Ryzen 3000 with a serious microcode bug in its random number generator." "Windows users couldn't successfully launch Destiny 2, and Linux users in many cases couldn't even get their system to boot." https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/ https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd...
    - djmips 7y ago
      The article currently states the Destiny 2 issue was unrelated to the bug in the random number generator.

creato 7y ago

See the caveat at the end: > It is also possible that the resulting code path has some precision loss or other problems on AMD hardware. I have not tested for that! Intel doesn't test it either, which is why they disable it. You could argue that they should test and enable on AMD CPUs, but this isn't clearly scummy behavior (to me), it's not a zero cost decision they made solely to screw over AMD. Buying the hardware and testing it has a cost. It may not even be possible to test it to the same degree they test their own hardware. There may be modes, subtle differences between architecture versions, etc. that are hard to know about to test for.

nemetroid 7y ago
Until the opposite has been shown, the assumption should be that a CPU that indicates that it supports AVX2 does support AVX2.
- roenxi 7y ago
  That is not the case, this is at the boundary of software and hardware and real-world concerns dominate. It is quite possible that a library highly optimised to a specific hardware set could have ghastly bugs on hardware it isn't tested on and testing has a cost. Intel is being reasonable and in a sense prudent by only supporting hardware they understand very well. It isn't like they are sending the lawyers out to sue anyone writing high performance code on AMD chips - that would be unreasonable.
  - the8472 7y ago
    The usual approach (e.g. taken in the linux kernel, llvm, hotspot jvm) is to look at the cpuid capability flags and rely on them by default and only blacklist specific CPU models when they don't implement advertised features correctly, not the other way around.
  - yxhuvud 7y ago
    Then don't test it. It is perfectly ok (and even expected) for Intel to not test on AMD. Just don't intentionally cripple it.

jandrewrogers 7y ago

The caveat at the end of the article is grounded in reality. I've personally experienced material precision bugs when running Intel-targeted code on AMD microarchitectures. These edge cases are very difficult to test for. The only reason we ever detected instances of these bugs is because we ran numerical codes at massive scales (finding the edge cases by brute force) and customers occasionally ran identical test workloads across both Intel and AMD clusters and compared numerical results. Every so often, something would surface. It is not Intel's responsibility to ensure that there is no obscure edge case in AMD's microarchitecture that may cause the MKL algorithms to give incorrect results on AMD silicon. MKL's design is based in part on Intel knowing the internal details of their own silicon.

Dylan16807 7y ago
Correct, it's not their responsibility to avoid AMD bugs. So if switching from fast possibly-buggy instructions to slow possibly-buggy instructions is some lazy attempt at avoiding bugs, they should stop doing it.
jchw 7y ago
> MKL's design is based in part on Intel knowing the internal details of their own silicon. This is just conjecture unless there’s a citation to support it. Besides, the microarchitecture design is bound to change dramatically over time just as a matter of course. Relying on things that they don’t document publicly is probably not a wise strategy. How would the teams coordinate not breaking each-other? I can imagine such a position would be incredibly unpopular amongst those working on silicon designs (and maybe not popular amongst those working on software, either.) Also, nobody has really presented a reasoning that justifies this behavior, since if it broke on AMD hardware, it still wouldn’t be Intel’s problem, and therefore perhaps they should just use the instruction sets as intended and documented instead.
- jandrewrogers 7y ago
  This is literally discussed in the MKL documentation, which spends considerable time on numerical reproducibility across microarchitectures. You have a rather strong opinion for someone who can't be bothered to educate themselves on the subject matter. I'm not an Intel fanboi but casually dismissing this specific issue is just ignorance. Intel's algorithms, for better and worse, are very aware of the limitations of their silicon implementations.

deleted 7y ago

[deleted]

zepearl 7y ago

Is the "MKL" mentioned by the article referring to https://docs.anaconda.com/mkl-optimizations/ https://docs.anaconda.com/mkl-optimizations/ (or something similar)? If yes, then there is apparently an active engagement by Intel (therefore involving people&money) and I don't see anything wrong if they optimize their code for their CPUs and then ignore other manufacturers (AMD) - mooost probably they just don't have a reason about why they should improve their competition + trying to do that anyway (without having full insight about the "foreign" multiple CPU architectures) might generate even worse performance which in turn would backfire (e.g. "aaahh Intel is sabotaging AMD CPUs"). So, personally I would have no problem if when using iMKL ("intel MKL") the code would run faster on Intel CPUs by default and being conservative on other CPUs - but if I would own an AMD CPU then I would expect AMD to implement some similar optimization for their own CPUs (aMKL?).

gameswithgo 7y ago
what you are talking about isn’t the situation. they are intentionally detecting cpu features wrong so as to not use features amd cpus have. nobody is expecting special amd optimization attention.
- zepearl 7y ago
  Ok, if it's like that ("intentionally detecting cpu features wrong") then I would agree. Can a "CPU feature" (e.g. sse2, avx, aes, etc...) be implemented the same way between different architectures?
  - gallexme 7y ago
    (Until someone has a more detailed answer) Both Intel and AMD are on the same X86 architecture, and sse2 etc are just extensions of the X86 architecture, u can check which feature flags a CPU has And the call/use of these features is the same for AMD or Intel
    - BeeOnRope 7y ago
      They explicitly look for the "GenuineIntel" product string and then basically disable all the efficient code paths if it isn't found, totally against their own advice for ISA extension detection [1]. https://www.agner.org/optimize/blog/read.php?i=49 https://www.agner.org/optimize/blog/read.php?i=49