Live data from Hacker News

AVX-512, what’s useful for us

obe.tv

11–20 of 50 posts

Re: AVX-512, what’s useful for us

#11

It will be a while before AVX-512 becomes practical however. AMD doesn't support it (so any RyZen or Threadripper fans will miss out), and even Intel 8th Gen Coffee-lake doesn't support it. Only Intel Extreme i9 and Xeon Silver / Gold / Platinum seems to support it. So the market for this instruction set is quite limited.

Only if you're writing general purpose software. We're taking advantage of AVX-512 in HPC since the cost of re-writing the software to take advantage of the hardware is a smart investment due to the large capital costs involved.

Re: AVX-512, what’s useful for us

#12
post #5

Earlier quoted context omitted.

FWIW we're only one generation away from AVX512 on consumer CPUs, Intel's upcoming Cannon Lake architecture will support it. https://www.anandtech.com/show/11928/intels-document-points-...

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 b…

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

Re: AVX-512, what’s useful for us

#13

If I'm understanding it correctly, they're not actually using the 512 bit (ZMM) registers, because using them can cause overall system slowdown. It seems to me they're only really useful if you're doing an AVX-512 intensive workload. And do those really exist? For something like bulk matrix multiplications, GPGPU is going to be much better, both in throughput and in operations per joule. I'm remaining to be convinced…

> For something like bulk matrix multiplications, GPGPU is going to be much better, both in throughput and in operations per joule.

But you have to get all of your matrix out onto the system bus, and over to the GPU, then start the kernel, and then copy it all the way back again, to use that. ZMM is just a register. You can operate on it immediately and stream data from memory while you do the multiply.

Re: AVX-512, what’s useful for us

#14

If I'm understanding it correctly, they're not actually using the 512 bit (ZMM) registers, because using them can cause overall system slowdown. It seems to me they're only really useful if you're doing an AVX-512 intensive workload. And do those really exist? For something like bulk matrix multiplications, GPGPU is going to be much better, both in throughput and in operations per joule. I'm remaining to be convinced…

They only cause slowdown on some models, if you pay Intel enough they wont. The advantage of AVX512 is you can use it on every core (rather than trying to work out how to partition a GPU), and it is useful for lots of general purpose computations.

Re: AVX-512, what’s useful for us

#15
post #9

Earlier quoted context omitted.

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 b…

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.

Re: AVX-512, what’s useful for us

#16

If I'm understanding it correctly, they're not actually using the 512 bit (ZMM) registers, because using them can cause overall system slowdown. It seems to me they're only really useful if you're doing an AVX-512 intensive workload. And do those really exist? For something like bulk matrix multiplications, GPGPU is going to be much better, both in throughput and in operations per joule. I'm remaining to be convinced…

They only cause slowdown on some models, if you pay Intel enough they wont. The advantage of AVX512 is you can use it on every core (rather than trying to work out how to partition a GPU), and it is useful for lots of general purpose computations.

What models don't slow down? Are you claiming the slowdown isn't actually necessary to keep the chip stable?

Re: AVX-512, what’s useful for us

#17
post #12

Earlier quoted context omitted.

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 b…

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.

Re: AVX-512, what’s useful for us

#18
post #9

Earlier quoted context omitted.

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 b…

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

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.

Re: AVX-512, what’s useful for us

#19
post #9

Earlier quoted context omitted.

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 b…

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

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)

Post reply on HN