5 ms·

For those not in the know here, Intel's actually had some fairly ok AVX-512 implementations on consumer chips in the past, even if they do cause the whole chip

For those not in the know here, Intel's actually had some fairly ok AVX-512 implementations on consumer chips in the past, even if they do cause the whole chip to downclock significantly. But for the new Alder Lake cpu, which has P/E Performance/Efficiency cores, the efficiency cores don't have AVX-512, so code would have to find a way to switch modes it runs in as it is shuffled between cores. So generally, AVX-512 is regarded as not-actually-available on Alder Lake.

raisin_churn 4y ago
> so code would have to find a way to switch modes it runs in as it is shuffled between core It's even worse than that. Initially you could disable E-cores in BIOS to get the system to report AVX-512 being available, but Intel released a microcode update to remove this workaround[0]. Intel also stated that they started fusing off the AVX-512 in silicon on later production Alder Lake chips[1]. Also compare the Ark entries for the Rocket Lake[2], Alder Lake[3], and Raptor Lake[4] flagships. Only the 11900k lists AVX-512 as an available Instruction Set Extension. So it's reasonable to say that AVX-512 on consumer Intel lines is dead for now, whereas AMD has just introduced it in the Ryzen 7000 series. [0] https://www.tomshardware.com/news/intel-reportedly-kills-avx-512-alder-lake-cpus https://www.tomshardware.com/news/intel-reportedly-kills-avx... [1] https://www.intel.com/content/www/us/en/support/articles/000089918/processors.html https://www.intel.com/content/www/us/en/support/articles/000... [2] https://ark.intel.com/content/www/us/en/ark/products/212325/intel-core-i911900k-processor-16m-cache-up-to-5-30-ghz.html https://ark.intel.com/content/www/us/en/ark/products/212325/... [3] https://ark.intel.com/content/www/us/en/ark/products/134599/intel-core-i912900k-processor-30m-cache-up-to-5-20-ghz.html https://ark.intel.com/content/www/us/en/ark/products/134599/... [4] https://ark.intel.com/content/www/us/en/ark/products/230496/intel-core-i913900k-processor-36m-cache-up-to-5-80-ghz.html https://ark.intel.com/content/www/us/en/ark/products/230496/...
- herpderperator 4y ago
  Does anyone know why they would do this? If AVX-512 works fine on P-cores, and if certain people disable E-cores because they want to use AVX-512, why would they stop those who want to from being able to use it? Why would they go to such extreme lengths to disable something?
  - paulmd 4y ago
    Nobody really knows for sure. The immediate problem is that CPUID is not deterministic for naive software, if you don't set affinity-masks you don't know whether you will be scheduled onto p-cores or e-cores, and so the result you get will vary. More generally, software doesn't know what configurations of threads to launch... you want to launch as many AVX-512 threads as you have logical cores, but not more, because they won't run on e-cores. Software could potentially run a cpuid instruction affine to each logical core though, and collate the results... all you need know is "16 logical cores with AVX-512 and 4 without". And software that isn't AVX-512 aware doesn't need to worry about it at all, since it doesn't know AVX-512 instructions. I guess the long tail of support is the stuff written for Skylake-SP in the meantime, but how much adoption really is there? It's that narrow gap between "regular stuff that never adopted AVX-512 because it wasn't on consumer platform" and "stuff that isn't HPC enough to be really custom" but also "stuff that won't receive an update". How much software can that really describe, especially with the reaction against Skylake-SP's clockdowns in mixed AVX-512+non-AVX workloads? And also, that software can just launch AVX-512 threads and if they end up on the e-cores you trap the instruction and affine them to the p-cores. Linux already has support for this because Linux doesn't save AVX registers if there have never been AVX instructions used, so, it just would become another type of interrupt for that first AVX-512 instruction. Linus has commented that this is perfectly feasible and he's puzzled why they're not doing it too. Nobody knows what the fuck is going on and there has been no plan expressed to anyone outside the company as to what the exact problem is and whether they're looking at anything to fix it going forward. It's a complete mystery, nobody even knows if it's something critical or everything is just too on-fire to care about that right now. (and if it wasn't on fire before, it probably is now, nobody you want to retain is hanging around after a 20% pay cut off the top and truly insulting retention bonuses... ranging as high as $200 for a senior principal (no, that is not missing a "K"). Oh and we paid $4b in dividends, and you need to move to Ohio if you want to keep your job, yes the ohio with the cancer cloud. Intel is fucked.)
  - eyegor 4y ago
    Perhaps market segmentation, perhaps they heard of a vulnerability in their implementation that they couldn't patch (hence the microcode update). Intel loves market segmentation (server specific avx extensions, bfloat, ecc, overclocking), and I wouldn't be shocked to see them sell avx512 support as a "dlc" microcode update down the road.
kristianp 4y ago
I wonder what Intel's plan is for the future here. Will a future efficiency core support AVX-512? Or will intel just abandon it on consumer in favor of a variable-length simd instruction set?
- paulmd 4y ago
  Crestmont is the next e-core after gracemont and appears to still not have AVX-512. It would be highly desirable for e-cores to implement microcoded AVX-512 support to break the heterogeneous-ISA problem, if nothing else. You don't need to use the same implementation but if you can support the same ISA via microcode then software doesn't need to worry about heterogeneous ISA. Maybe crestmont does the microcode thing, possibly, but in the die shots there aren't many visible changes in the vector unit vs gracemont design. The next p-core will continue to have AVX-512 but it will continue to be fused off. This obviously is completely insane, like, even if you validated Raptor Cove already and you can't just take AVX-512 out, you're just going to keep including it in all your future designs too? It's not an insignificant amount of area, even on consumer it's probably at least 10% extra area just to even support a 256b vector/microcode, and it just looks crazy to introduce and then abandon it at the exact moment your competitor adopts and supports it. Only thing I can think of is that maybe they have some other instructions which utilize microcode intrinsics implemented on the AVX-512 engines... like how Turing implements its Rapid Packed Math (dual-rate FP16) support using the tensor engines. Something else in the design that locks them into AVX-512 even if it is not externally exposed? But again, they don't even support it even if you turn off the e-cores entirely... why the fuck would you do that? It's like the most confusing resolution to this problem and satisfies nobody, probably not even Intel. I guess they flatly do not want to touch it at all for some reason. Note that this also includes mobile going forward since mobile will have big.LITTLE designs too... it's a serious amount of work and years of rollout they're pissing down the drain here.
  - kristianp 4y ago
    Perhaps there wasn't enough lead time to get it into Crestmont after the decision to go with P+E for Alder Lake.
  - 4y ago

raisin_churn 4y ago

> so code would have to find a way to switch modes it runs in as it is shuffled between core It's even worse than that. Initially you could disable E-cores in BIOS to get the system to report AVX-512 being available, but Intel released a microcode update to remove this workaround[0]. Intel also stated that they started fusing off the AVX-512 in silicon on later production Alder Lake chips[1]. Also compare the Ark entries for the Rocket Lake[2], Alder Lake[3], and Raptor Lake[4] flagships. Only the 11900k lists AVX-512 as an available Instruction Set Extension. So it's reasonable to say that AVX-512 on consumer Intel lines is dead for now, whereas AMD has just introduced it in the Ryzen 7000 series. [0] https://www.tomshardware.com/news/intel-reportedly-kills-avx-512-alder-lake-cpus https://www.tomshardware.com/news/intel-reportedly-kills-avx... [1] https://www.intel.com/content/www/us/en/support/articles/000089918/processors.html https://www.intel.com/content/www/us/en/support/articles/000... [2] https://ark.intel.com/content/www/us/en/ark/products/212325/intel-core-i911900k-processor-16m-cache-up-to-5-30-ghz.html https://ark.intel.com/content/www/us/en/ark/products/212325/... [3] https://ark.intel.com/content/www/us/en/ark/products/134599/intel-core-i912900k-processor-30m-cache-up-to-5-20-ghz.html https://ark.intel.com/content/www/us/en/ark/products/134599/... [4] https://ark.intel.com/content/www/us/en/ark/products/230496/intel-core-i913900k-processor-36m-cache-up-to-5-80-ghz.html https://ark.intel.com/content/www/us/en/ark/products/230496/...

herpderperator 4y ago
Does anyone know why they would do this? If AVX-512 works fine on P-cores, and if certain people disable E-cores because they want to use AVX-512, why would they stop those who want to from being able to use it? Why would they go to such extreme lengths to disable something?
- paulmd 4y ago
  Nobody really knows for sure. The immediate problem is that CPUID is not deterministic for naive software, if you don't set affinity-masks you don't know whether you will be scheduled onto p-cores or e-cores, and so the result you get will vary. More generally, software doesn't know what configurations of threads to launch... you want to launch as many AVX-512 threads as you have logical cores, but not more, because they won't run on e-cores. Software could potentially run a cpuid instruction affine to each logical core though, and collate the results... all you need know is "16 logical cores with AVX-512 and 4 without". And software that isn't AVX-512 aware doesn't need to worry about it at all, since it doesn't know AVX-512 instructions. I guess the long tail of support is the stuff written for Skylake-SP in the meantime, but how much adoption really is there? It's that narrow gap between "regular stuff that never adopted AVX-512 because it wasn't on consumer platform" and "stuff that isn't HPC enough to be really custom" but also "stuff that won't receive an update". How much software can that really describe, especially with the reaction against Skylake-SP's clockdowns in mixed AVX-512+non-AVX workloads? And also, that software can just launch AVX-512 threads and if they end up on the e-cores you trap the instruction and affine them to the p-cores. Linux already has support for this because Linux doesn't save AVX registers if there have never been AVX instructions used, so, it just would become another type of interrupt for that first AVX-512 instruction. Linus has commented that this is perfectly feasible and he's puzzled why they're not doing it too. Nobody knows what the fuck is going on and there has been no plan expressed to anyone outside the company as to what the exact problem is and whether they're looking at anything to fix it going forward. It's a complete mystery, nobody even knows if it's something critical or everything is just too on-fire to care about that right now. (and if it wasn't on fire before, it probably is now, nobody you want to retain is hanging around after a 20% pay cut off the top and truly insulting retention bonuses... ranging as high as $200 for a senior principal (no, that is not missing a "K"). Oh and we paid $4b in dividends, and you need to move to Ohio if you want to keep your job, yes the ohio with the cancer cloud. Intel is fucked.)
- eyegor 4y ago
  Perhaps market segmentation, perhaps they heard of a vulnerability in their implementation that they couldn't patch (hence the microcode update). Intel loves market segmentation (server specific avx extensions, bfloat, ecc, overclocking), and I wouldn't be shocked to see them sell avx512 support as a "dlc" microcode update down the road.

kristianp 4y ago

I wonder what Intel's plan is for the future here. Will a future efficiency core support AVX-512? Or will intel just abandon it on consumer in favor of a variable-length simd instruction set?

paulmd 4y ago
Crestmont is the next e-core after gracemont and appears to still not have AVX-512. It would be highly desirable for e-cores to implement microcoded AVX-512 support to break the heterogeneous-ISA problem, if nothing else. You don't need to use the same implementation but if you can support the same ISA via microcode then software doesn't need to worry about heterogeneous ISA. Maybe crestmont does the microcode thing, possibly, but in the die shots there aren't many visible changes in the vector unit vs gracemont design. The next p-core will continue to have AVX-512 but it will continue to be fused off. This obviously is completely insane, like, even if you validated Raptor Cove already and you can't just take AVX-512 out, you're just going to keep including it in all your future designs too? It's not an insignificant amount of area, even on consumer it's probably at least 10% extra area just to even support a 256b vector/microcode, and it just looks crazy to introduce and then abandon it at the exact moment your competitor adopts and supports it. Only thing I can think of is that maybe they have some other instructions which utilize microcode intrinsics implemented on the AVX-512 engines... like how Turing implements its Rapid Packed Math (dual-rate FP16) support using the tensor engines. Something else in the design that locks them into AVX-512 even if it is not externally exposed? But again, they don't even support it even if you turn off the e-cores entirely... why the fuck would you do that? It's like the most confusing resolution to this problem and satisfies nobody, probably not even Intel. I guess they flatly do not want to touch it at all for some reason. Note that this also includes mobile going forward since mobile will have big.LITTLE designs too... it's a serious amount of work and years of rollout they're pissing down the drain here.
- kristianp 4y ago
  Perhaps there wasn't enough lead time to get it into Crestmont after the decision to go with P+E for Alder Lake.
- 4y ago