15 ms·

Point of order! The core of the RISC-V ISA was already designed by the time ARMv8-A was announced on 27 October 2011. I don't think anyone anticipated it -- ce

Point of order! The core of the RISC-V ISA was already designed by the time ARMv8-A was announced on 27 October 2011. I don't think anyone anticipated it -- certainly I remember it being a complete surprise to me. Here is the RISC-V design as at 13 May 2011: https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.... Compare that to the design eventually ratified in 2019 and you'll find some changes in details, but not in concept. - instructions encodings changed to e.g. put rd on the right next to the opcode and the MSBs of literals on the left. - J and JAL are now combined - JALR had three versions (in func3) to distinguish call / return / others. This is now done as a convention which registers are used in rd and rs1. (It matters only for a return address prediction stack, an advanced feature) - RDNPC (get address of next instruction) later turned into AUIPC (which includes adding an offset to the PC) - on the other hand, it already has the very RISC-V feature of loads using rd and rs1 while stores use rs1 and rs2 (and the offset split up differently). Most other ISAs (including all Arm ISAs) use the same register fields for loads and stores and the offset in the same place, resulting in either loads using rs2 as the destination or stores using rd as a source! Seriously, other than the changes mentioned above, this document looks just like the final RV32G/RV64G spec from ratification in 2019. (I didn't check the floating point instructions in detail). As for SIMD -- RISC-V was designed as the control processor for an advanced length agnostic vector processor. F*ck fixed length SIMD.

neonsunset 2y ago
> F*ck fixed length SIMD. There is the issue. It goes completely against how the current landscape of SIMD support looks like and what everything is optimized around (it's fixed length SIMD, variable length has huge issues getting mapped onto anything that isn't auto-vectorization). Now, I'm not a fan of RISC-V so, if anything, I encourage their way of doing RVV. Makes it more likely to die.
- brucehoult 2y ago
  I don't see how it will die when it can imitate fixed length SIMD very easily. Not to mention that Arm too is pushing length-agnostic vector computing -- not very hard so far, admittedly, and they haven't yet departed from the 128 bit NEON vector register length. The very first SVE implementation, by Fujitsu, used 512 bit vector registers. And was the fastest supercomputer in the world for a while, so the concept is not obviously rubbish.
  - dzaima 2y ago
    RVV can imitate NEON, but will it perform anywhere near reasonably on hardware? With NEON, you can be sure that the hardware will be optimized around 128-bit operations and thus comfortably use it for such. Whereas RISC-V hardware with 512-bit vectors might only get quarter throughput if you only need the low 128 bits (and that could end up slower than doing scalar code! whereas on ARM you can be pretty damn sure than 1×128-bit NEON won't be slower than 2×64-bit scalar or some SWAR). Much as I like RVV, fixed-width use-cases still exist and are pretty important for CPU SIMD; scalable vectors work well for very-many-iteration embarrassingly parallel loops, but those are also things most suited for being moved to a GPU. Where CPUs have the most potential is in things with some dependency chain or small loops, for which scalable vectors largely just add questionability of performance.
    - brucehoult 2y ago
      Obviously using 128 bit vector length on a machine with 512 bit vector registers is not using all the performance you paid for, but it's not going to be slower than using a machine with 128 bit vector registers! Parallel operation on multiple data items is parallel operation on multiple data items. The developers of the dav1d software AV1 decoder found that RVV on a Kendryte K230 [1] performed no worse than NEON on an A53 on their small fixed-size transforms on video CODEC blocks. https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s [1] THead C908 core, very similar to the old C906 core found in e.g. the $3 Milk-V Duo, but dual-issue and with the RVV updated from draft 0.7 to ratified 1.0
      - dzaima 2y ago
        > but it's not going to be slower than using a machine with 128 bit vector registers! It very well could; for example, RVV hardware with VLEN=512, one 512-bit vector ALU, and three scalar ALUs (float or integer), would have 512 bits/cycle with vector and 192 bits/cycle for scalar (i.e. vector at VLMAX is beneficial!), but using only 128 bits of the vectors would end up with just 128b/cycle. And this is just regular ALU instructions, vrgather can get significantly worse, and it is extremely important for most fixed-width stuff. This of course wouldn't ever happen with actually-128-bit hardware as it wouldn't ever make sense to have such vector vs scalar distribution for its guaranteed-128-bit workloads. And, though perhaps my previous example is a tad extreme, with higher VLEN it gets more and more reasonable to have a larger gap between scalar and vector ALU/port counts, and maintaining 'vector_alu_count*2 ≥ scalar_alu_count' gets less and less reasonable. K230 is irrelevant here - it has VLEN=128, which is the optimal thing for being used as a fixed-width system / imitating NEON. And, more generally, looking at just one RVV implementation cannot give any insight on how well the "scalable" part of RVV works, as that only applies when running the same code across multiple different implementations with different VLEN. Could high-VLEN hardware still be made such that 128-bit usage is never strictly worse than scalar? Perhaps. But there exist incentives under which it might not make sense to have such, which have no possible equivalent on NEON/x86, and apply specifically when the "scalable" part of RVV is actually used for its intended purpose in hardware.

neonsunset 2y ago

> F*ck fixed length SIMD. There is the issue. It goes completely against how the current landscape of SIMD support looks like and what everything is optimized around (it's fixed length SIMD, variable length has huge issues getting mapped onto anything that isn't auto-vectorization). Now, I'm not a fan of RISC-V so, if anything, I encourage their way of doing RVV. Makes it more likely to die.

brucehoult 2y ago
I don't see how it will die when it can imitate fixed length SIMD very easily. Not to mention that Arm too is pushing length-agnostic vector computing -- not very hard so far, admittedly, and they haven't yet departed from the 128 bit NEON vector register length. The very first SVE implementation, by Fujitsu, used 512 bit vector registers. And was the fastest supercomputer in the world for a while, so the concept is not obviously rubbish.
- dzaima 2y ago
  RVV can imitate NEON, but will it perform anywhere near reasonably on hardware? With NEON, you can be sure that the hardware will be optimized around 128-bit operations and thus comfortably use it for such. Whereas RISC-V hardware with 512-bit vectors might only get quarter throughput if you only need the low 128 bits (and that could end up slower than doing scalar code! whereas on ARM you can be pretty damn sure than 1×128-bit NEON won't be slower than 2×64-bit scalar or some SWAR). Much as I like RVV, fixed-width use-cases still exist and are pretty important for CPU SIMD; scalable vectors work well for very-many-iteration embarrassingly parallel loops, but those are also things most suited for being moved to a GPU. Where CPUs have the most potential is in things with some dependency chain or small loops, for which scalable vectors largely just add questionability of performance.
  - brucehoult 2y ago
    Obviously using 128 bit vector length on a machine with 512 bit vector registers is not using all the performance you paid for, but it's not going to be slower than using a machine with 128 bit vector registers! Parallel operation on multiple data items is parallel operation on multiple data items. The developers of the dav1d software AV1 decoder found that RVV on a Kendryte K230 [1] performed no worse than NEON on an A53 on their small fixed-size transforms on video CODEC blocks. https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s https://www.youtube.com/watch?v=asRnBcn5VKs&t=9m40s [1] THead C908 core, very similar to the old C906 core found in e.g. the $3 Milk-V Duo, but dual-issue and with the RVV updated from draft 0.7 to ratified 1.0
    - dzaima 2y ago
      > but it's not going to be slower than using a machine with 128 bit vector registers! It very well could; for example, RVV hardware with VLEN=512, one 512-bit vector ALU, and three scalar ALUs (float or integer), would have 512 bits/cycle with vector and 192 bits/cycle for scalar (i.e. vector at VLMAX is beneficial!), but using only 128 bits of the vectors would end up with just 128b/cycle. And this is just regular ALU instructions, vrgather can get significantly worse, and it is extremely important for most fixed-width stuff. This of course wouldn't ever happen with actually-128-bit hardware as it wouldn't ever make sense to have such vector vs scalar distribution for its guaranteed-128-bit workloads. And, though perhaps my previous example is a tad extreme, with higher VLEN it gets more and more reasonable to have a larger gap between scalar and vector ALU/port counts, and maintaining 'vector_alu_count*2 ≥ scalar_alu_count' gets less and less reasonable. K230 is irrelevant here - it has VLEN=128, which is the optimal thing for being used as a fixed-width system / imitating NEON. And, more generally, looking at just one RVV implementation cannot give any insight on how well the "scalable" part of RVV works, as that only applies when running the same code across multiple different implementations with different VLEN. Could high-VLEN hardware still be made such that 128-bit usage is never strictly worse than scalar? Perhaps. But there exist incentives under which it might not make sense to have such, which have no possible equivalent on NEON/x86, and apply specifically when the "scalable" part of RVV is actually used for its intended purpose in hardware.