3 ms·

MMX was 64-bit wide, SSE 128-bit wide and AVX 256-bit wide, and they succeeded each other rapidly (when compared to the situation now). AVX512 is another doubli

MMX was 64-bit wide, SSE 128-bit wide and AVX 256-bit wide, and they succeeded each other rapidly (when compared to the situation now). AVX512 is another doubling, so what's the hold up with this one compared to the previous two doublings? Maybe it's time for AMD to do something about this, like when they took the initiative to create x86-64

arcticbull 5y ago
As the 4th doubling, that's a 16X increase over the base. 512-bit registers, ALUs, data paths, etc, are all really really physically big.
mcronce 5y ago
Zen 4 is reported to have AVX-512 support. I'm not sure if that'll be included on Ryzen or not, though; only Epyc is "confirmed" as far as I know.
- jhgb 5y ago
  It would be strange if AMD didn't offer this on Ryzens. First, they don't have a history of locking people out of instruction sets. Second, they need it for being competitive with Intel anyway. Third, they're using the same die for multiple purposes, not like Intel with separate server dies for Xeons.
monocasa 5y ago
My sense is that it's because it happened about when Intel's litho progress began stalling out. It was designed for a world the uarch folks were expecting with smaller transistors than they ended up getting.
snek_case 5y ago
The right thing to do IMO would be to have vector instructions with a variable number of operands. Quit adding wider instructions, just tell the instruction how many operands you want to add/multiply and let the CPU take care of it. This could also allow the CPU to decide what's the most efficient way to prefetch, etc., or to run these operations asynchronously.
- paulmd 5y ago
  That's exactly what ARM did with SVE, so it's easy to discuss the pros and cons. The biggest problem, to my understanding, is that SIMD extensions are mostly targeted with optimized hand-written assembly code. It's fine to say that the SIMD is variable-width, but you still have to run this on a processor where the hardware is not variable-width. Not just the SIMD unit, but also the feedpaths/etc. And some things a "generic" framework might let you do, might have catastrophic performance consequences. In practice a lot of this will be avoided by just knowing the hardware you're going to target and not doing the things that hurt performance, but that also completely misses the point of variable-width, you might as well just target the hardware directly at that point. And actually your data may not be "variable-width" either.
  - snek_case 5y ago
    It seems to me it's extremely common to work with vectors that are much larger than the host CPU's SIMD width. In that case you could get much better performance letting the CPU schedule a large batch of work rather than trying to micro-optimize for multiple possible targets. Software is typically compiled for x86-64, but not necessarily for each specific x86-64 processor available. You often just get a generic precompiled binary. That's not really optimized for the machine you're running the software on. Maybe you want to have some restrictions on the size of the vectors you're working with to make it more convenient for the hardware, like "should be a multiple of 4x64 bits", but I still think there could be big gains with variable width in most cases.
  - vlovich123 5y ago
    I thought the same but that’s not how that works. It’s variable width at the assembly level. You give it entire buffers with the total length and it internally uses the appropriate width (or tells you the width it used during the loop? I forget that detail). Anyway, it’s not a SW framework but a core part of the CPU implemented in Hw.
  - BeeOnRope 5y ago
    That's not how SVE works. Any given SVE CPU still has a fixed vector width at runtime, but the CPU exposes instructions which tell you the vector width and other convenience instructions for performing loop counter math and handling the "final" iteration which may not use a full vector. Then you need to write your loops in such a way that they work with a variable width: i.e., doing more iterations if the vector width is smaller.

arcticbull 5y ago

As the 4th doubling, that's a 16X increase over the base. 512-bit registers, ALUs, data paths, etc, are all really really physically big.

mcronce 5y ago

Zen 4 is reported to have AVX-512 support. I'm not sure if that'll be included on Ryzen or not, though; only Epyc is "confirmed" as far as I know.

jhgb 5y ago
It would be strange if AMD didn't offer this on Ryzens. First, they don't have a history of locking people out of instruction sets. Second, they need it for being competitive with Intel anyway. Third, they're using the same die for multiple purposes, not like Intel with separate server dies for Xeons.

monocasa 5y ago

My sense is that it's because it happened about when Intel's litho progress began stalling out. It was designed for a world the uarch folks were expecting with smaller transistors than they ended up getting.

snek_case 5y ago

The right thing to do IMO would be to have vector instructions with a variable number of operands. Quit adding wider instructions, just tell the instruction how many operands you want to add/multiply and let the CPU take care of it. This could also allow the CPU to decide what's the most efficient way to prefetch, etc., or to run these operations asynchronously.

paulmd 5y ago
That's exactly what ARM did with SVE, so it's easy to discuss the pros and cons. The biggest problem, to my understanding, is that SIMD extensions are mostly targeted with optimized hand-written assembly code. It's fine to say that the SIMD is variable-width, but you still have to run this on a processor where the hardware is not variable-width. Not just the SIMD unit, but also the feedpaths/etc. And some things a "generic" framework might let you do, might have catastrophic performance consequences. In practice a lot of this will be avoided by just knowing the hardware you're going to target and not doing the things that hurt performance, but that also completely misses the point of variable-width, you might as well just target the hardware directly at that point. And actually your data may not be "variable-width" either.
- snek_case 5y ago
  It seems to me it's extremely common to work with vectors that are much larger than the host CPU's SIMD width. In that case you could get much better performance letting the CPU schedule a large batch of work rather than trying to micro-optimize for multiple possible targets. Software is typically compiled for x86-64, but not necessarily for each specific x86-64 processor available. You often just get a generic precompiled binary. That's not really optimized for the machine you're running the software on. Maybe you want to have some restrictions on the size of the vectors you're working with to make it more convenient for the hardware, like "should be a multiple of 4x64 bits", but I still think there could be big gains with variable width in most cases.
- vlovich123 5y ago
  I thought the same but that’s not how that works. It’s variable width at the assembly level. You give it entire buffers with the total length and it internally uses the appropriate width (or tells you the width it used during the loop? I forget that detail). Anyway, it’s not a SW framework but a core part of the CPU implemented in Hw.
- BeeOnRope 5y ago
  That's not how SVE works. Any given SVE CPU still has a fixed vector width at runtime, but the CPU exposes instructions which tell you the vector width and other convenience instructions for performing loop counter math and handling the "final" iteration which may not use a full vector. Then you need to write your loops in such a way that they work with a variable width: i.e., doing more iterations if the vector width is smaller.