Cray-1 vs Raspberry Pi

Yeah but no one is burying the plastic, it’s too expensive. So realistically I’d much rather have the plastic breakdown so it’s not everywhere for 10k years.

I'm not sure it is difficult to see why variable length SIMD makes sense. If you want to process 15 elements with a width of 8, you will need the function twice, once with SIMD processing whole batches of 8 elements and a scalar version of the same function to process the last 7 elements. This makes it inherently difficult to write SIMD code even in the simple and happy case of data parallelism. With RISC-V all you do is set vlen to 7 in the last iteration.

>what do you even pass to vsetvl in this case as you don’t know your string length.

I'm not sure what you are trying to say here. You must know the length of the buffer, if you don't know the length of the buffer, then processing the string is inherently sequential, just like reading from a linked list, since accessing even a single byte beyond the null terminator risks a buffer overflow. Why pick an example that can't be vectorized by definition?

Not the Cray-1, but the Navy used a Cray 90 a few years later for CFD calculations modeling flow around ship hulls (code written in Fortran).

I wish I had access to the code I wrote back then - what took minutes or hours on the Cray could probably run in seconds on a RPi now…

> if you wait a few years might not be worth to pay for cray right away

And then you don’t get anything done because there is always a better computer just around the corner. Most of the time, proposals are written for hardware that already exist and don’t need the absolute best. If you have some CFD or MHD calculations to do for a rocket engine or a nuclear reactor, you don’t care about the computer on which it ran, just that it ran on time and did not hold the whole project back. Even cutting edge science does not require cutting edge hardware most of the time.

Just like buying a desktop next year won’t help you play games today, at some point you have to settle and accept that your hardware will be outdated by the time it comes online (it’s a bit better now, but leading HPC clusters still get obsolesced quite quickly).

> maybe this was before moores law though

The exponential character of available CPU time on larger computers was apparent before Moore’s law.

> what do you even pass to vsetvl in this case as you don’t know your string length.

To the maximum, of course, `vsetvl x, x0, ...` will do that for you.

You might read over a page boundery, but there is an instruction for that `vle8ff.v`, it's a fault-only-first uni-stride load. That is, it doesn't fault when one of the later elements goes outside our page, and adjusts the vector length accordingly. [0]

> With the various simd extensions on x86 or arm, such a routine could be carefully written to align with cache lines and so avoid depending on reading the next line when the string ends before it.

In practice, on current very early hardware, doing just that is faster, and definitely possible. [1]

> I also worry about various simd tricks that seem to rely on the width. Eg I think there’s some instruction to interpret each half-byte of one vector as an index into some vector of 16 things

I'm not aware of such an instruction, but rvv has vrgather.vv and vrgatherei16.vv to do something similar. Note that you can always return to "fixed-size" implementations if you really need to, buy just setting the vl accordingly. But for the most part I don't think this will be necessary. Do you have any specific problem in mind that may seem hard to do without fixed size SIMD?

> I guess part of my thinking here is that the ISA designers at intel, arm, aren’t stupid, but they ended up with fixed widths for sse, neon, knights landing, avx, avx-512.

I mean, ARM now has something similar with SVE, and x86 has a metric ton of legacy to work with and the market size to get adoption of whatever new instruction prefix they add. Edit: Also, didn't AVX10/AVX512vl go into a similar direction as SVE?

> Is there something reasonable written about why risc-v went with this design.

I'm not quite sure, but I remember that it was one thing from very early in the design. I think it's to have a mostly unified ecosystem for the binary app market. It also makes working with mixed precision easier, because it allows for the LMUL model.

But RISC-V is extendable, the P (Packed SIMD) extension is currently in the works and aimed at the embedded market, for in GPR SIMD operations for DSP type applications. [2]

[0] https://github.com/riscv/riscv-v-spec/blob/master/example/st...

[1] https://camel-cdr.github.io/rvv-bench-results/canmv_k230/str...

[2] https://lists.riscv.org/g/tech-p-ext/topics