3 ms·

This is literally discussed in the MKL documentation, which spends considerable time on numerical reproducibility across microarchitectures. You have a rather s

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.

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.