> […] an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) […] I am not sure how to parse the «simpler, i.e. better» part;

> […] an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) […] I am not sure how to parse the «simpler, i.e. better» part; simplicity vs betterness is orthogonal at best and is contradictory at worst. Very few people write meticulously handcrafted, highly optimised code for any ISA today, and the compiler writers actually prefer a more complex ISA as it becomes easier for them to transalate high level programming abstractions into an efficient concrete hardware implementation and run it through an optimising pass. Simplicity of the ISA does not immediately translate into faster or more optimised code. Moreover, creating a highly efficient optimiser is no easy feat as it depends on a large variety of factors and the in-depth knowledge of a specific CPU incarnation: the knowledge of each instruction's timing, instruction interdependencies (i.e. the most optimal instruction sequence that does not stall the pipeline or maximises the ALU/whatever utilisation etc etc), L1 I and D cache line sizes, the knowledge of a particular CPU model / generation… – and that is just a beginning. There is a good reason why Intel, AMD, IBM, ARM et al publish hefty optimisation guidelines / documents for each generation of their CPU's with the compiler writers in mind: the same sequence of instructions issued for the CPU model 123 might be less (or more) efficient than in the next CPU model 456 and vice versa; moreover (e.g. specifically for Intel vs AMD), a sequence of instructions optimised for a particular Intel generation might underperform for an equivalent AMD model or vice versa. Same is likely to be true for different RISC-V core designs from different RISC-V vendors. This is the reason why -mcpu=XXX and -mtune=YYY exist in GCC and clang/LLVM: efficient low-level code optimisation is a tricky business and depends on a large number of compounding factors. It remains to be seen how the optimisation will be tackled in the RISC-V case with its potpourri of optional ISA extensions and also with the instruction fusion. Given that a random concrete RISC-V implementation can be a combination of the base ISA + a random permutation of any RISC-V extensions (in the worst case scenario), emitting the code that will run equally efficient across N different RISC-V core designs appears to be problematic. Instruction fusion can pose another challenge as a fused macro-instruction may or may not run as efficiently on a RISC-V instance that does not fuse them. There is no guarantee that the compiler generated / optimised code will be equally highly performant across different implementations even for the same set of ISA extensions.