4 ms·

That's the maximum error. The error is often much less than that (as the plot shows). Code might unintentionally be relying on the error being much smaller than

by creato 7y ago

That's the maximum error. The error is often much less than that (as the plot shows). Code might unintentionally be relying on the error being much smaller than the spec requires, and on another architecture, the instruction might not meet this (unintentional!) requirement. Of course an issue stemming from something like this is rare/unlikely. But Intel also can't assume that the consequences for a related error are small. It seems like most people commenting irately about this in this thread are hobbyists or are otherwise working on low consequence software. Yeah, for these uses, it would probably make sense for intel to just look at the CPUID and leave it at that. But they can't know that, and they aren't optimizing solely for these use cases.

jchw 7y ago
I am suggesting that if Intel does not care about their code running on AMD processors, then it should not arbitrarily change behavior based on the presence of the string “GenuineIntel.” End of story. But I suspect Intel does care, in the sense that they certainly care about how they perform and benchmark against AMD. Let’s put it another way. What happens if Intel enables AVX2 for AMD and it doesn’t work? 1. Precision is not as good as intel? 1.a. Many developers care and it impacts AMD negatively. (Probably nothing happens since nothing is actually broken per se.) 1.b. Few developers care and it suggests Intel is not optimizing for the best performance trade-off. 2. Programs using MKL crash on AMD processors. 2.a. There is a bug in MKL: it probably gets fixed with little fanfare. 2.b. There is a bug on AMD processors, and it probably gets fixed in microcode. 3. AMD processors produce wrong results. There seems like there can only be one outcome here, and it’s probably worse for AMD than Intel. The Intel FDIV bug proves that people take these things very seriously. At best it could be fixed in microcode, and at absolute worst AVX2 could be disabled entirely in an update. The best argument for why Intel would still rationally avoid AVX2 on AMD outside of the above is to ensure their customer’s code runs correctly on AMD processors. However, there’s still some problems: - They have to contend with their own processors, too. If they write code they know depends on non-public details of the architecture, they could very well break themselves. - What is the definition for “break?” Intel surely has test suites for their software, but just because the software’s precision may be worse (still pure conjecture) when running under AMD does not suggest it is broken. All we can say is that users may rely on the behavior of precision on their specific configuration, but the problem is that’s not specific to AMD. Intel alludes to the fact that precision can be different amongst Intel processors in several places on MKL’s documentation. Nothing stops someone from improperly relying on this. By playing fast and loose with specifying an architecture then writing software that disregards it, I’m not sure how defensible a position Intel is sitting in from pretty much any perspective. > “otherwise working on low consequence software” No offense but it is hard to respectfully respond to something like this, even though I know it wasn't directed at me personally. I hope you don’t think about coworkers with this mindset.
- creato 7y ago
  > Let’s put it another way. What happens if Intel enables AVX2 for AMD and it doesn’t work? The "safe" thing to do is rather than work through all of these cases you've considered, is to just give up on it. > No offense but it is hard to respectfully respond to something like this, even though I know it wasn't directed at me personally. I hope you don’t think about coworkers with this mindset. I didn't intend it to be disrespectful. It's not a value judgement. Maybe these aren't the best terms, but I've worked on both what I would call "low consequence" software, and "high consequence" software. The tolerance for decision making about things like swapping out hardware is different. In some cases, this can be done with little hesitation. In other cases, it would cost millions of dollars to test the system to the point where it could be trusted. Maybe the solution to the internet pitchfork wielders is for intel to simply stop trying to serve both of these sets of users with the same software. But I suspect they simply don't care about this problem enough to do anything.
  - yxhuvud 7y ago
    But they don't give up, they fall back to SSE. Which ALSO might have exactly the same issues as AVX2 instructions.
    - creato 7y ago
      They probably fall back to SSE2, which is the least supported SSE on any 64-bit x86 processor. That might be their minimum/baseline codepath and don't want to build/maintain any other code paths.

by creato 7y ago

jchw 7y ago

I am suggesting that if Intel does not care about their code running on AMD processors, then it should not arbitrarily change behavior based on the presence of the string “GenuineIntel.” End of story. But I suspect Intel does care, in the sense that they certainly care about how they perform and benchmark against AMD. Let’s put it another way. What happens if Intel enables AVX2 for AMD and it doesn’t work? 1. Precision is not as good as intel? 1.a. Many developers care and it impacts AMD negatively. (Probably nothing happens since nothing is actually broken per se.) 1.b. Few developers care and it suggests Intel is not optimizing for the best performance trade-off. 2. Programs using MKL crash on AMD processors. 2.a. There is a bug in MKL: it probably gets fixed with little fanfare. 2.b. There is a bug on AMD processors, and it probably gets fixed in microcode. 3. AMD processors produce wrong results. There seems like there can only be one outcome here, and it’s probably worse for AMD than Intel. The Intel FDIV bug proves that people take these things very seriously. At best it could be fixed in microcode, and at absolute worst AVX2 could be disabled entirely in an update. The best argument for why Intel would still rationally avoid AVX2 on AMD outside of the above is to ensure their customer’s code runs correctly on AMD processors. However, there’s still some problems: - They have to contend with their own processors, too. If they write code they know depends on non-public details of the architecture, they could very well break themselves. - What is the definition for “break?” Intel surely has test suites for their software, but just because the software’s precision may be worse (still pure conjecture) when running under AMD does not suggest it is broken. All we can say is that users may rely on the behavior of precision on their specific configuration, but the problem is that’s not specific to AMD. Intel alludes to the fact that precision can be different amongst Intel processors in several places on MKL’s documentation. Nothing stops someone from improperly relying on this. By playing fast and loose with specifying an architecture then writing software that disregards it, I’m not sure how defensible a position Intel is sitting in from pretty much any perspective. > “otherwise working on low consequence software” No offense but it is hard to respectfully respond to something like this, even though I know it wasn't directed at me personally. I hope you don’t think about coworkers with this mindset.

creato 7y ago
> Let’s put it another way. What happens if Intel enables AVX2 for AMD and it doesn’t work? The "safe" thing to do is rather than work through all of these cases you've considered, is to just give up on it. > No offense but it is hard to respectfully respond to something like this, even though I know it wasn't directed at me personally. I hope you don’t think about coworkers with this mindset. I didn't intend it to be disrespectful. It's not a value judgement. Maybe these aren't the best terms, but I've worked on both what I would call "low consequence" software, and "high consequence" software. The tolerance for decision making about things like swapping out hardware is different. In some cases, this can be done with little hesitation. In other cases, it would cost millions of dollars to test the system to the point where it could be trusted. Maybe the solution to the internet pitchfork wielders is for intel to simply stop trying to serve both of these sets of users with the same software. But I suspect they simply don't care about this problem enough to do anything.
- yxhuvud 7y ago
  But they don't give up, they fall back to SSE. Which ALSO might have exactly the same issues as AVX2 instructions.
  - creato 7y ago
    They probably fall back to SSE2, which is the least supported SSE on any 64-bit x86 processor. That might be their minimum/baseline codepath and don't want to build/maintain any other code paths.