3 ms·

But AVX512 has been killed on Alder Lake also -- not that I was too excited about it, but it's certainly sapping my interest in Intel in the short and medium te

But AVX512 has been killed on Alder Lake also -- not that I was too excited about it, but it's certainly sapping my interest in Intel in the short and medium term. All because only P cores can execute AVX512 and E cores will fault on those instructions. Can't let programs using them affinitize themselves to P cores only, oh no. Definitely need to kill the entire instruction set extension, or only allow it if BIOS writers figure out they can use unpublished methods to enable it but only if they disable E cores at boot. /s (I may be wrong on some details above, I haven't been keeping the closest of eyes on the issues.)

ranger_danger 5y ago
My understanding is that AVX512 is not all that it's cracked up to be anyway, and that it also clocks the CPU down while it is executing those instructions. So my understanding is that a program (even if not a particularly heavy one) that constantly executed AVX512 instructions could cause a noticeable drop in performance to the entire system.
- dundarious 5y ago
  Agreed, wasn't too excited about it as a prospect because of reports like that, but now it'll be even harder to test for myself, and if it turns out to have _some_ use case, it's another generation before consumer grade stuff can benefit from it. Completely off my radar now.
- atq2119 5y ago
  I haven't been following the Alder Lake situation too closely, but AVX512 is really multiple things that ought to have been orthogonal: (1) 512-bit vectors, (2) a much cleaner vector instruction set, (3) masked vector instructions. It's mildly understandable that Intel didn't want to implement (1) on the E cores (though it would arguably have been better to just dual-issue them, like AMD did for 256-bit vectors on the original Zens). But there's no reason not to implement (2) and (3) on the E cores. Perhaps somebody will clarify that (2) and (3) are available on Alder Lake, that would take a lot of the hurt out of this announcement, but it does sound like they're not -- and that's a major bummer.
  - q-big 5y ago
    > It's mildly understandable that Intel didn't want to implement (1) on the E cores (though it would arguably have been better to just dual-issue them, like AMD did for 256-bit vectors on the original Zens). But there's no reason not to implement (2) and (3) on the E cores. It is very likely that all these aspects are very hard to separate from each other.

ranger_danger 5y ago

My understanding is that AVX512 is not all that it's cracked up to be anyway, and that it also clocks the CPU down while it is executing those instructions. So my understanding is that a program (even if not a particularly heavy one) that constantly executed AVX512 instructions could cause a noticeable drop in performance to the entire system.

dundarious 5y ago
Agreed, wasn't too excited about it as a prospect because of reports like that, but now it'll be even harder to test for myself, and if it turns out to have _some_ use case, it's another generation before consumer grade stuff can benefit from it. Completely off my radar now.
atq2119 5y ago
I haven't been following the Alder Lake situation too closely, but AVX512 is really multiple things that ought to have been orthogonal: (1) 512-bit vectors, (2) a much cleaner vector instruction set, (3) masked vector instructions. It's mildly understandable that Intel didn't want to implement (1) on the E cores (though it would arguably have been better to just dual-issue them, like AMD did for 256-bit vectors on the original Zens). But there's no reason not to implement (2) and (3) on the E cores. Perhaps somebody will clarify that (2) and (3) are available on Alder Lake, that would take a lot of the hurt out of this announcement, but it does sound like they're not -- and that's a major bummer.
- q-big 5y ago
  > It's mildly understandable that Intel didn't want to implement (1) on the E cores (though it would arguably have been better to just dual-issue them, like AMD did for 256-bit vectors on the original Zens). But there's no reason not to implement (2) and (3) on the E cores. It is very likely that all these aspects are very hard to separate from each other.