3 ms·
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 waste
by 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.
- dmitrygr 2y agoIt’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.