[_chris_]

Very different. RISC-V's vectors (RVV) are "variable length", so the programmer can request a length and the machine tells you what it can give you. Different machine versions can change the underlying vector size and the code Will Just Work.

This is different from "fixed-width SIMD" which has a hard-coded vector length. To make things more challenging for the programmer/compiler, I believe most x86 SIMD versions also don't provide a "mask" register, so you're stuck with using all vector elements (AVX512 added masks).

Each has its advantages and disadvantages (esp. on the design complexity vs programmer/compiler interface complexity).

RVV also provides a mechanism to reconfigure the register file, ganging logical registers together to get longer effective vector lengths.

[volta83]

Can you change the "shape of the vectors? e.g. 1x16 vs 4x4 to support vectors and matrices?

[crest]

You have widening operations e.g. 16x16->32 bit multiplications and can reduce number of available registers to get longer vectors, but among the really interesting ones are fault only first load and masked instructions that enable the vector unit to work on things like null terminated strings. The specification includes vectorized strlen/strcmp/strcpy/strncpy implementations as examples. Most existing (packed) SIMD instruction sets aren't useful for these common functions.

[jcranmer]

Given the number of implementations of str* routines in https://github.com/bminor/glibc/tree/master/sysdeps/x86_64/m..., maybe you might want to revisit your last statement. PCMP/MOVMSK work well enough for finding the trailing NUL.

[crest]

Now compare how many different versions of the functions are required for the dozens of possible x86 extensions (and combinations of them) and all the prologue/epilogue code required to watch out for page boundaries and unaligned pointers and as well as the length of the inner loop to handle all the packing/unpacking and cobbeling together horizontal operations to the required masks and turn somehow use them for flow control where needed. It's enough code to put painful pressure on the instruction cache and requires wide OoO superscalar CPU cores to be worth the overhead compare the code in the RISC V vector spec with this strcmp https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/m... and tell me it's a clean and straightforward implementation using the instruction set as intended and not an ugly hack around its limitations.

[jcranmer]

I'm not going to dispute that x86's approach leads to a lot of duplication for each vector size, but your statement was that the fixed-size vector approach isn't "useful for these common functions," which implies to me that it couldn't be used at all.

[mhh__]

Has anyone actually used these in anger? I see the potential over fixed width SIMD, but what's it like to actually program in C++?

Who is going to write all the documentation and snippets for them? RISC-V docs seem to be mostly pdf based which isn't great.

[Taniwha]

I'm not an expert but I've seem them characterised as "the return of Cray vectors", so maybe yes

[mhh__]

Cray's were programmed in assembly though.

[garmaine]

So is risc-v…?

[mhh__]

No it's obviously not going to be. You can write X86 SIMD code extremely effectively from a high level language. I want to write RISC-V/V code in C++, but if it ends up as carting around fixed width vectors then that's a loss.

[garmaine]

I’m horribly confused. x86 SIMD has the fixed width vectors, not RISC-V or Cray.