Hacker News Reader

Comment by _chris_ | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

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.

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

Cray's were programmed in assembly though.

So is risc-v…?

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.

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

My 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.

That you can program in x86 SIMD in a high-level language and find it intuitive to use is remarkable. It was not designed for that and exposes primitives which make more sense for assembly-level and automatic compiler optimization. Cray, on the other hand, has a vector ISA that is explicitly designed for integration into high-level languages. You basically write a "for loop" like instruction which sets up the source and dest arrays, then do regular scalar operations (add, multiply, etc.) using virtual source & destination registers. It feels just like coding the CPU's integer APU. The CPU itself handles the magic of parallelizing these operations across its vector units.

So sorry I was a bit confused because Cray/RISC-V is explicitly designed to be easy to use from high-level languages in a way that x86's SSE et al were not. So I thought maybe you had mixed up the two in your question or something. But I guess you just haven't had the pleasure of working with a Cray before!

Can you show me any source code of a Cray being programmed in a high level language? What you describe sounds like a higher level ISA, but that has to be easily expressed in C++ for the argument to hold (or alternatively any high level language available at the time).

The thing with the Intel model is that although the programming model in the abstract is probably worse (although I'm curious if it allows a wider processor), it is trivial to use conceptually if you understand roughly which instructions you want i.e. it's just a blob as far as the compiler is concerned.

The compiler I work on supports Intel SIMD, I'm not sure it could be easily made to get the most out of a vector programming model without a lot of rewrites. It could, however, basically emulate the fixed width things in terms of a vector ISA if needs be.

See the #pragma directives in this document:

http://www.audentia-gestion.fr/CRAY/PDF/Cray_C_and_C___Refer...

You literally just write regular old C code doing a tight inner-loop computation, and use pragmas to tell the compiler what it needs to safely parallelize.

Of course these days you can do the same thing in any vectorizing compiler. But the point is that a modern vectorizing compiler has to do some pretty impressive transformations to generate SIMD code which looks nothing like the original, whereas the Cray code pretty much compiles to the same thing when vectorized.

I think we've been talking past eachother (I should have been more direct perhaps). This programming model is not what I had in mind - I completely accept your point about the Cray model but I meant something slightly dumber than loop parallelization.

In very tight situations it's common to write SIMD intrinsics directly rather than rely on the compilers ability to make the transformations itself. Intel's SIMD maybe be ugly but it is also very topologically easy to navigate, if that makes sense.

I'm going to write some arm SVE code and compare, at some point.

Yeah the point with the Cray vector opcodes is that the SIMD instructions ARE the regular scalar/FPU instructions. The compiler doesn’t do anything to different when it vectorizes the loop. It is the CPU that does the vector optimization. The code just provides hints (to the CPU, not the compiler) about how to vectorize.

Reply on news.ycombinator.com