7 ms·
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 m
by _chris_ 5y ago
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 5y agoCan you change the "shape of the vectors? e.g. 1x16 vs 4x4 to support vectors and matrices?
- crest 5y agoYou 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 5y agoGiven the number of implementations of str* routines in https://github.com/bminor/glibc/tree/master/sysdeps/x86_64/multiarch 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 5y agoNow 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/multiarch/strcmp-sse2-unaligned.S 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 5y agoI'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__ 5y agoHas 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 5y agoI'm not an expert but I've seem them characterised as "the return of Cray vectors", so maybe yes
- mhh__ 5y agoCray's were programmed in assembly though.
- garmaine 5y agoSo is risc-v…?
- mhh__ 5y agoNo 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 5y agoI’m horribly confused. x86 SIMD has the fixed width vectors, not RISC-V or Cray.
- mhh__ 5y agoMy question is whether it's possible to get the most out of a variable width vector architecture from a high level language. If this is not the case then our programming model may end up being the same as it is on X86 since it's a easy subset of the functionality.