4 ms·

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 microar

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.
  - jchw 7y ago
    I am sitting here without a citation of any kind. edit: In retrospect this comes off as unnecessarily snarky. Let me clarify: - I am just asking for a specific citation about this issue. - Reproducibility is one case where details about microarchitectures matter, but it is not actually the default behavior of MKL, and the documentation makes it clear that its limitations are largely unrelated to the normal operation of MKL; for example: https://software.intel.com/en-us/mkl-windows-developer-guide-obtaining-numerically-reproducible-results https://software.intel.com/en-us/mkl-windows-developer-guide... > Dispatching optimized code paths based on the capabilities of the processor on which the code is running is central to the optimization approach used by Intel MKL. So it is natural that consistent results require some performance trade-offs. If limited to a particular code path, performance of Intel MKL can in some circumstances degrade by more than a half. To understand this, note that matrix-multiply performance nearly doubled with the introduction of new processors supporting Intel AVX2 instructions. Even if the code branch is not restricted, performance can degrade by 10-20% because the new functionality restricts algorithms to maintain the order of operations. This bit here is pretty important because it suggests that strict CNR mode can disable AVX2 codepaths even on Intel. It isn't doing so on AMD specifically for reproducibility; it just won't load AVX2 codepaths on non-Intel processors, period.
    - atq2119 7y ago
      It's a shame this comment is downvoted, considering that it's the first one to clearly show that the reproducibility argument for MKL's behaviour is bogus: MKL purposefully crippling AMD's performance does nothing for reproducibility between the microarchitectures, because to get proper reproducibility you have to cripple the performance on both AMD and Intel. And of course that's not what Intel's doing by default.
robocat 7y ago
Can you indicate how often the issues you detected were bugs in the Intel CPUs?
- jandrewrogers 7y ago
  As I recall (and I am pulling from stale memory), we generally concluded that Intel had the more strictly correct behavior. Our numerical algorithms were designed in Julia and we had some pretty rigorous formal models for what they should be producing. I had a similar experience compiling complex C++ code bases in both GCC and Clang. There were interesting edge cases that cropped up where the compilers apparently had a fundamental disagreement on how to interpret a bit of code. Every time we did deep dive to understand the discrepancy, we came to the conclusion that Clang was probably correct strictly speaking. This still caused us problems and we ended up designing work arounds to support GCC.
shawnz 7y ago
> 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. So then why let MKL run on AMD CPUs at all?

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.
- jchw 7y ago
  I am sitting here without a citation of any kind. edit: In retrospect this comes off as unnecessarily snarky. Let me clarify: - I am just asking for a specific citation about this issue. - Reproducibility is one case where details about microarchitectures matter, but it is not actually the default behavior of MKL, and the documentation makes it clear that its limitations are largely unrelated to the normal operation of MKL; for example: https://software.intel.com/en-us/mkl-windows-developer-guide-obtaining-numerically-reproducible-results https://software.intel.com/en-us/mkl-windows-developer-guide... > Dispatching optimized code paths based on the capabilities of the processor on which the code is running is central to the optimization approach used by Intel MKL. So it is natural that consistent results require some performance trade-offs. If limited to a particular code path, performance of Intel MKL can in some circumstances degrade by more than a half. To understand this, note that matrix-multiply performance nearly doubled with the introduction of new processors supporting Intel AVX2 instructions. Even if the code branch is not restricted, performance can degrade by 10-20% because the new functionality restricts algorithms to maintain the order of operations. This bit here is pretty important because it suggests that strict CNR mode can disable AVX2 codepaths even on Intel. It isn't doing so on AMD specifically for reproducibility; it just won't load AVX2 codepaths on non-Intel processors, period.
  - atq2119 7y ago
    It's a shame this comment is downvoted, considering that it's the first one to clearly show that the reproducibility argument for MKL's behaviour is bogus: MKL purposefully crippling AMD's performance does nothing for reproducibility between the microarchitectures, because to get proper reproducibility you have to cripple the performance on both AMD and Intel. And of course that's not what Intel's doing by default.

robocat 7y ago

Can you indicate how often the issues you detected were bugs in the Intel CPUs?

jandrewrogers 7y ago
As I recall (and I am pulling from stale memory), we generally concluded that Intel had the more strictly correct behavior. Our numerical algorithms were designed in Julia and we had some pretty rigorous formal models for what they should be producing. I had a similar experience compiling complex C++ code bases in both GCC and Clang. There were interesting edge cases that cropped up where the compilers apparently had a fundamental disagreement on how to interpret a bit of code. Every time we did deep dive to understand the discrepancy, we came to the conclusion that Clang was probably correct strictly speaking. This still caused us problems and we ended up designing work arounds to support GCC.

shawnz 7y ago

> 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. So then why let MKL run on AMD CPUs at all?