Well, one-generation away from consumers being able to buy the chip. And maybe 5-years away before a sizable number of consumers upgrade to that chip (or newer)... since the typical Desktop is at LEAST 5 years old in my experience...

The Users who really need the feature are likely upgrading to AVX-512 computers already. IE: Mac Pro. So adoption is not as bad as my hyperbole above. But its still going to be a while before we can assume AVX512 support on machines.

Hell, with so many people running Sandy Bridge (i7-2xxx series), you can't even assume AVX2 support today.

That is the beauty of JIT compilers, some JVMs like Azul's already support it.

Some of the AVX512 instruction set seems very well suited for automatic JIT compilers. I'm sure Azul immediately jumped on board for the "Conflict Detection" instruction set and are auto-vectorizing tons of more loops.

But other AVX512 instructions don't seem very easy for compilers to automatically apply. In particular: Scatter/Gather instructions have implications on the most-efficient way to lay out data in memory. I'm sure an auto-vectorizer can take advantage of it slightly, but it'd take an AVX512 expert to determine the best memory-layout for various data-structures in this new AVX512 world.

Although I guess an auto-vectorizer could use those instructions to handle more cases... smart programmers would still have to tune their code (or really: their data-structures) to be done in such a way that the auto-vectorizer / optimizing compilers can utilize these instructions.

AFAIK, scatter/gather have been available in supercomputer vector ISA's since the mid-1970'ies. And even with the state of compiler technology back then, the Cray Fortran compiler was able to use scatter/gather to vectorize loops with indirect addressing (e.g. a[ind[i]] ). Such as occurs e.g. in sparse matrix style computations.

Couldn't you use something like GCC function multi-versioning?

AVX512 has so many more features above-and-beyond Intel's typical SIMD implementation. Feature wise, its beginning to be competitive against NVidia's PTX CUDA architecture. Like, AVX512 is a really, really good instruction set (or I guess: a really good set of instruction sets).

Assuming AVX512 F, CD, VL, DQ, and BW (the expected AVX512 instructions in CannonLake):

* AVX512F -- "Standard" 512-bit arithmetic already has major improvements, above and beyond the 256bit -> 512bit upgrade. AVX512 has 32-registers per core (when AVX2 and earlier only have 16). The new set of opmask instructions also allow for way more code to turn into "branch-free" code which is friendly for pipelines. This is already a major step forward alone with huge implications for multimedia code.

* AVX512-CD: Conflict Detection. These instructions allow auto-vectorizers to "resolve loop conflicts" and auto-vectorize more code.

* VL, DQ -- Extend AVX512 to Bytes, Shorts, Longs, Long Longs.

* BW -- Extend AVX512 to operate on only 256-bit and 128-bits at a time.

--------------------

I'm certain that some code, which could not be vectorized in AVX2 (or lower), will be vectorized with AVX512. Maybe even automatically as compiler writers implement high-level features / auto-vectorizers.

I wonder why they did the BW thing instead of just defining a vector length register like other vector ISA's (which would have allowed to get rid of a remainder loop, leading to less code bloat and more efficient execution for short loops where the number of iterations is not an integer multiple of the ISA vector length).

VL - Extend AVX512 to operate on only 256-bit and 128-bits at a time. (vector length extension)

DQ - Extend AVX512 to Longs, Long Longs. (double word and quadword extension)

BW - Extend AVX512 to Bytes, Shorts. (byte and word extension)

Intel did a self goal here by limiting availability of AVX512 to select Xeon SKUs.

Yep. If you use Intel ISPC to write vector code (and you should, it's seriously underrated) it can also target multiple instruction sets and dispatch to the best supported one at runtime.

Yes, that or manual runtime dispatching. Which is doable if there are only a few hot-spots in the code.

It'd be so sweet if multi-versioning became well supported across all major compilers (including MSVC)