4 ms·

It'd make more sense to compare with a RISC-V that has Vector 1.0. Because a vector machine is what it was.

by snvzz 3y ago

cmrdporcupine 3y ago
Well, or compare to a GPU or a TPU
- snvzz 3y ago
  Those are largely simd but not vector.
  - cmrdporcupine 3y ago
    That's fair. I haven't spent any time looking through the RISC-V vector extensions yet. I look forward to it, though.
    - rwmj 3y ago
      They are said to be "inspired" by classic Cray vector instructions, although I have of course never used a Cray :-( so I can't comment on how true that is. I did use a Convex C2[0] for a while which also had real vector instructions, but it was all hidden behind a compiler option. [0] https://en.wikipedia.org/wiki/Convex_Computer https://en.wikipedia.org/wiki/Convex_Computer
  - dan-robertson 3y ago
    How is vector different from simd?
    - IshKebab 3y ago
      The RISC-V Vector extension allows the vector length to vary at runtime whereas with SIMD the vector length is fixed at compile time (128 bit, 256 bit etc.). It means the code is more portable basically. With x86 SIMD the standard solution is to compile the same code multiple times for different SIMD widths (using different instructions) and then detect the CPU at runtime. Though that is such a pain that it's only really done in explicitly numerical libraries (Numpy, Eigen, etc.). In theory with Vector you can compile once, run anywhere.
      - dan-robertson 3y ago
        That design seems like a reasonable thing for a high level language that could then be converted to different architectures’ simd widths. But I’m kinda surprised it’s good at the ISA level. Eg for something like a vectorized strlen, mightn’t one worry that the cpu would choose vlen[1] too large causing you to load from cache lines (or pages!) that turn out to be unnecessary for finding the length of the string. 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. 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. How could these be ported to risc-v? Or maybe that’s not the sort of thing their vector extensions are meant for. 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. Presumably they had reasons to prefer that to the dynamic risc-v style thing. So I wonder: are there some risc-v constraints the push this design (eg maybe low-power environments presumably pushed neon to have a small width and this made higher-power environments suffer; having a dynamic length might allow both to use the same machine code), or were there some reasons intel preferred to stick with fixed widths, eg making something that could only work on more expensive chips and thereby having something people can pay more for? Is there something reasonable written about why risc-v went with this design. [1] what do you even pass to vsetvl in this case as you don’t know your string length.
        imtringued 3y ago
        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?
- Findecanor 3y ago
  TPUs tend to be specialised for matrix multiplications, often at low precision.
voxadam 3y ago
Has anyone taped out a RISC-V CPU with hardware vector support yet?
- snvzz 3y ago
  Yes, several, with the Vector 1.0 specification. Some of them (Kendryte K230, a MCU) have already shipped to people. Years ago, some chips shipped, with 0.7.1 (incompatible, pre-ratification). One of them is the TH1520, SoC in some SBCs released earlier this year.

It'd make more sense to compare with a RISC-V that has Vector 1.0. Because a vector machine is what it was.

by snvzz 3y ago

It'd make more sense to compare with a RISC-V that has Vector 1.0. Because a vector machine is what it was.

cmrdporcupine 3y ago

Well, or compare to a GPU or a TPU

snvzz 3y ago
Those are largely simd but not vector.
- cmrdporcupine 3y ago
  That's fair. I haven't spent any time looking through the RISC-V vector extensions yet. I look forward to it, though.
  - rwmj 3y ago
    They are said to be "inspired" by classic Cray vector instructions, although I have of course never used a Cray :-( so I can't comment on how true that is. I did use a Convex C2[0] for a while which also had real vector instructions, but it was all hidden behind a compiler option. [0] https://en.wikipedia.org/wiki/Convex_Computer https://en.wikipedia.org/wiki/Convex_Computer
- dan-robertson 3y ago
  How is vector different from simd?
  - IshKebab 3y ago
    The RISC-V Vector extension allows the vector length to vary at runtime whereas with SIMD the vector length is fixed at compile time (128 bit, 256 bit etc.). It means the code is more portable basically. With x86 SIMD the standard solution is to compile the same code multiple times for different SIMD widths (using different instructions) and then detect the CPU at runtime. Though that is such a pain that it's only really done in explicitly numerical libraries (Numpy, Eigen, etc.). In theory with Vector you can compile once, run anywhere.
    - dan-robertson 3y ago
      That design seems like a reasonable thing for a high level language that could then be converted to different architectures’ simd widths. But I’m kinda surprised it’s good at the ISA level. Eg for something like a vectorized strlen, mightn’t one worry that the cpu would choose vlen[1] too large causing you to load from cache lines (or pages!) that turn out to be unnecessary for finding the length of the string. 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. 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. How could these be ported to risc-v? Or maybe that’s not the sort of thing their vector extensions are meant for. 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. Presumably they had reasons to prefer that to the dynamic risc-v style thing. So I wonder: are there some risc-v constraints the push this design (eg maybe low-power environments presumably pushed neon to have a small width and this made higher-power environments suffer; having a dynamic length might allow both to use the same machine code), or were there some reasons intel preferred to stick with fixed widths, eg making something that could only work on more expensive chips and thereby having something people can pay more for? Is there something reasonable written about why risc-v went with this design. [1] what do you even pass to vsetvl in this case as you don’t know your string length.
      - imtringued 3y ago
        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?
Findecanor 3y ago
TPUs tend to be specialised for matrix multiplications, often at low precision.

voxadam 3y ago

Has anyone taped out a RISC-V CPU with hardware vector support yet?

snvzz 3y ago
Yes, several, with the Vector 1.0 specification. Some of them (Kendryte K230, a MCU) have already shipped to people. Years ago, some chips shipped, with 0.7.1 (incompatible, pre-ratification). One of them is the TH1520, SoC in some SBCs released earlier this year.