8 ms·

> but I am allergic to RISC-V for personal reasons. Do you mind elaborating?

by tromp 2y ago

dmitrygr 2y ago
I find the instruction set distasteful. I don’t want to start a flame war. This is just my opinion, but it is a strong one. It was designed late enough in history to have taken advantage of a lot of available information. None of it was taken advantage of. Which is why a lot of extensions are now being proposed to actually fix things that should’ve been done right in the first place. With all the additions, it is slowly approaching sanity, only 10 years later. And I don’t buy the excuses that the learning process needed to happen. All the information was available all along, and the mistakes were obvious to basically all of us all along Some of the extensions are only Band-Aids for the real design issues. Eg shadd2 is a bandaid for not having proper addressing modes for accessing arrays. A common refrain to answer this is composed of promises of magical instruction fusion in the core. This is often promised, but never delivered. Certainly not in the cheap kind of processors that are the only target for RISC – V. Not having instructions for a bitfield extraction and insertion is also an amateur mistake. That’s why there are extensions to fix that one too. But it should’ve been obvious from the beginning that it would be necessary. A conditional branch based on a bit in a register is another obvious thing that should’ve been considered from the very beginning as it is commonly encountered. Any analysis of modern software would’ve shown this. What annoys me is the information was available. We know what sorts of things modern software does. It was all ignored. Instead, we got a slightly updated mips-1. And now with all the extensions, it’s fragmentation galore. You can either target the final result (RV23, I think is the name), which is somewhat sensible, but no hardware implements, or you can target the least common denominator, which will run everywhere, shittily There are other, more serious, design issues when it comes to attempting to use RISC – V for actual high-performance computing. I’ll save those for another rant. At approximately the same point in history, another instruction set was designed. It actually took advantage of all the knowledge available about what modern software looks like, and it shows: aarch64.
- mixmix 2y ago
  If I may ask, what's your absolute favorite ISA? Is it ARM64 or something less common/practical?
  - dmitrygr 2y ago
    For “big and fast”, aarch64. For “medium and small”, armv8M, for “very small”: AVR
- zozbot234 2y ago
  On the flip side, my understanding is that AArch64 does not support anything like RISC-V's 16-bit compressed instructions, which are trivial to implement in hardware and allow RISC-V code density to match and even beat x86-64 for real-world binaries. I think RISC-V's design criteria make plenty of sense on their own, they're just not the ones you might prefer.
  - dmitrygr 2y ago
    That was the other side of my rant that I alluded to and didn’t go into. The compressed instructions set is idiotic for big cores that need to go fast. It wastes 3/4 of the encoding space on nonsense that is of no use there. When you’re designing a big out of order core, slapping on a slightly bigger L1 is not a problem. Variable size instructions is one. Compare : Apple M4 perf vs $your_favourite_rv_”fast”_core perf per MHz It makes sense for micro controllers, but not for big cores. This whole approach of trying to be everything for everyone is one of the reasons that RISC – V ends up being mediocre for everyone and perfect for no one.
    - zozbot234 2y ago
      > Compare : Apple M4 perf vs $your_favourite_rv_”fast”_core perf per MHz We might get a meaningful comparison like that if Qualcomm starts making RISC-V based SoC's as a hedge against ARM. Or if Tenstorrent comes up with a M4-like CPU design. I think the jury is very much still out as to whether the rather limited variable-sized insns (2 or 4 bytes) of RISC-V + the compressed insn extension is a genuine concern. It's certainly nothing like the chaos you see with x86-64 (which seems to be a real bottleneck for very wide decode), and a lot closer to something like the old ARM32+Thumb2.

> but I am allergic to RISC-V for personal reasons. Do you mind elaborating?

by tromp 2y ago

> but I am allergic to RISC-V for personal reasons. Do you mind elaborating?

I find the instruction set distasteful. I don’t want to start a flame war. This is just my opinion, but it is a strong one. It was designed late enough in history to have taken advantage of a lot of available information. None of it was taken advantage of. Which is why a lot of extensions are now being proposed to actually fix things that should’ve been done right in the first place. With all the additions, it is slowly approaching sanity, only 10 years later. And I don’t buy the excuses that the learning process needed to happen. All the information was available all along, and the mistakes were obvious to basically all of us all along Some of the extensions are only Band-Aids for the real design issues. Eg shadd2 is a bandaid for not having proper addressing modes for accessing arrays. A common refrain to answer this is composed of promises of magical instruction fusion in the core. This is often promised, but never delivered. Certainly not in the cheap kind of processors that are the only target for RISC – V. Not having instructions for a bitfield extraction and insertion is also an amateur mistake. That’s why there are extensions to fix that one too. But it should’ve been obvious from the beginning that it would be necessary. A conditional branch based on a bit in a register is another obvious thing that should’ve been considered from the very beginning as it is commonly encountered. Any analysis of modern software would’ve shown this. What annoys me is the information was available. We know what sorts of things modern software does. It was all ignored. Instead, we got a slightly updated mips-1. And now with all the extensions, it’s fragmentation galore. You can either target the final result (RV23, I think is the name), which is somewhat sensible, but no hardware implements, or you can target the least common denominator, which will run everywhere, shittily There are other, more serious, design issues when it comes to attempting to use RISC – V for actual high-performance computing. I’ll save those for another rant. At approximately the same point in history, another instruction set was designed. It actually took advantage of all the knowledge available about what modern software looks like, and it shows: aarch64.

mixmix 2y ago
If I may ask, what's your absolute favorite ISA? Is it ARM64 or something less common/practical?
- dmitrygr 2y ago
  For “big and fast”, aarch64. For “medium and small”, armv8M, for “very small”: AVR
zozbot234 2y ago
On the flip side, my understanding is that AArch64 does not support anything like RISC-V's 16-bit compressed instructions, which are trivial to implement in hardware and allow RISC-V code density to match and even beat x86-64 for real-world binaries. I think RISC-V's design criteria make plenty of sense on their own, they're just not the ones you might prefer.
- dmitrygr 2y ago
  That was the other side of my rant that I alluded to and didn’t go into. The compressed instructions set is idiotic for big cores that need to go fast. It wastes 3/4 of the encoding space on nonsense that is of no use there. When you’re designing a big out of order core, slapping on a slightly bigger L1 is not a problem. Variable size instructions is one. Compare : Apple M4 perf vs $your_favourite_rv_”fast”_core perf per MHz It makes sense for micro controllers, but not for big cores. This whole approach of trying to be everything for everyone is one of the reasons that RISC – V ends up being mediocre for everyone and perfect for no one.
  - zozbot234 2y ago
    > Compare : Apple M4 perf vs $your_favourite_rv_”fast”_core perf per MHz We might get a meaningful comparison like that if Qualcomm starts making RISC-V based SoC's as a hedge against ARM. Or if Tenstorrent comes up with a M4-like CPU design. I think the jury is very much still out as to whether the rather limited variable-sized insns (2 or 4 bytes) of RISC-V + the compressed insn extension is a genuine concern. It's certainly nothing like the chaos you see with x86-64 (which seems to be a real bottleneck for very wide decode), and a lot closer to something like the old ARM32+Thumb2.