Comment by dmitrygr | Hacker News Reader

Comment by dmitrygr | Hacker News Reader

Parent Full thread

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.

>You can either target the final result (RV23, I think is the name), which is somewhat sensible

RVA23 is the name. And I hear this is what e.g. Windows, Android and the next Ubuntu LTS target.

>or you can target the least common denominator, which will run everywhere, shittily

Not as shitty as you make it to be. And it has a huge advantage to aarch64, in its simplicity. Easily an order of magnitude, allows it to be used in scenarios aarch64 could only dream of.

>At approximately the same point in history, another instruction set was designed

I get it, you really like aarch64.

Which one weighted its options better? You might be right, but as years pass we'll have the benefit of hindsight. We'll be able to look back and see whether either side had good choices or cursed ones.

It's going to be fun. Hasn't been this fun since the 90s.

For big cores that need to go fast, it is not even close of a comparison. Aarch64 is tuned to that

For small cheap stuff, sure, RV is ok. But so was AVR/ARMv6M/ARMv7M.

If I may ask, what's your absolute favorite ISA? Is it ARM64 or something less common/practical?

For “big and fast”, aarch64. For “medium and small”, armv8M, for “very small”: AVR

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.

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.

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

It’s been ten years. The jury has returned. Rendered judgement. Left to a picnic. Come back. And since retired to a carefree life of llama farming.

Your argument is wistful thinking. Not fact. “Well, if maybe someone does it” isn’t a fact. Maybe someone will make a 8501 that outperforms my M4. But I won’t believe it till it is done.

And indeed it is close to thumb2. Which was purposefully rejected for aarch64. By careful study. Given that between the two, aarch64 looks to be much better thought-through, I’ll be giving the credit for making the right decision here to that team too.

Reply on news.ycombinator.com