> This is why I can never get excited about Intel doing anything outside mainline x86.
This skepticism could reasonably be extended to x86 as well, given Intel's handling of AVX-512.
The inconsistent support for various subsets of AVX-512, on different processors, makes it hard to predict whether some future processor will have the particular instructions that matter to your software.
Despite outward appearances, AVX-512 follows two paths: server and consumer. Each year, the support on one tier is larger than before (until Alder Lake, that is). The various "sub instruction sets" are more for categorization reasons than differences in capability.
If you look at AVX-512's chart on Wikipedia[0], but reorder it into (the discontinued) Xeon Phi, server, and consumer tiers, it's a nice chart showing increasing support as time goes on. For example, -ER, -PF, -4FMAPS, and -4VNNIW weren't really "removed" after Xeon Phi because the server and consumer lines never had them. That chart is just horrible because it tries to show a timeline without clarifying the differences in tiers.
there still is the fundamental problem that most people who do compiler work mostly don't work on servers so Intel's strategy has kept avx 512 from having good support
> I think the biggest issue is that auto vectorization would need a programming language that is designed around it.
I don't think that's correct.
The compilers I work with do a pretty decent job of auto-vectorizing the inner-most loops of an algorithm, especially if they know the loop bounds at compile-time.
This skepticism could reasonably be extended to x86 as well, given Intel's handling of AVX-512.
The inconsistent support for various subsets of AVX-512, on different processors, makes it hard to predict whether some future processor will have the particular instructions that matter to your software.