RISC-V inferior to ARMv8

Adrian (a.delete@this.acm.org) on December 20, 2018 8:51 pm wrote:
> The RISC-V fans argue that the extra instructions do not matter, because a fast implementation will fuse
> the address computation instructions with the data handling instructions, achieving the same throughput.
>
>
> I do not agree, because I believe that it is stupid to code the address computation with an extra instruction
> word, when the same thing can be encoded with a couple of bits in an addressing mode field and the instruction
> decoder is also certainly simpler than the one that must fuse those instruction pairs.

Aren't these differences due to the fact ARMv8 has evolved from previous ARM ISAs over a few decades of real world use that showed where the weak points were, whereas RISC-V is mostly from an academic ivory tower purist background with very little real world usage? Sometimes you find you must compromise your purist principles to produce a better result, which is why ARMv8 adopted some features that aren't considered traditionally RISC.

The arguments made by the RISC-V fans sound a lot like arguments made by Itanium fans where the compiler would pick up the slack for the shortcomings, and the raw speed would enable it to beat all comers. But RISC-V fans aren't even claiming this will result in superior performance, only that it will be the same. If so, what's the point?

They are trading complexity in instruction decode for dynamic execution complexity. I think the performance that x86 is able to attain has shown us that instruction decode complexity matters little if at all given modern transistor budgets. Getting wider to issue and execute those index calculations as separate instructions in parallel, on the other hand, requires very careful design to insure all paths have enough resources without escalating power draw too much.