I don't agree with that. The base ISA is highly optimised for high performance. Many of the decisions made are precisely because it makes it easier to design very wide superscalar CPUs. The vector extension is also looking like it'll be more efficient than ARMs.
What's missing, is instruction set extensions that makes it comparable to ARM/x86 across all workloads. And obviously it's far less mature in general.
RISC-V has been optimized for a single-purpose, being as simple as possible to be easily taught to students and implemented by them in a limited time.
It lacks many features required for high performance without hardware of excessive complexity, the most obvious being that RISC-V does not have decent addressing modes, so that the highest performance implementation reported until now (by Alibaba at the 2020 Hot Chips Conference) had to add a non-standard ISA extension to correct this.
Nobody remotely competent chooses RISC-V for "high performance" in any definition of that term.
RISC-V can be the right choice in many cases because:
1. No costs for using the RISC-V ISA
2. Easy customization with non-standard extensions
3. An already existing complete software development environment, with compilers, debuggers etc.
4. Acceptable performance at a given implementation cost
There is no need to invent extra fictitious advantages, like "high performance".
It is actually a replacement for MIPS in a more literal sense: The company owning MIPS has recently renamed itself to MIPS, and it abandoned MIPS ISA in favor of RISC-V ISA.
Do you have any proof that additional addressing modes would increase performance? What I remember from college and papers I've read is that more modes are generally a detriment to pipelining.
Maybe you're talking about "needing more instructions". You'd be wrong in this case. Using the compact instruction set gives an average of 15% more dense code compared to x86 and somewhere around 25-35% more dense compared to aarch64 (about equivalent density to thumb, but without the switching overhead that makes thumb slow).
"Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension"
From "VIII. NON-STANDARD INSTRUCTION SET EXTENSION"
Targeting at various industrial applications, XT-910 enables a set of custom non-standard instructions, additional to the standard RISC-V instructions. The non-standard instruction extension can be categorized into two groups based on the purposes - memory access enhancement, and basic arithmetic operation enhancement.
A. Memory access enhancement
Memory access instructions usually account for a high proportion in the total number of instructions, so enhancing memory access instructions can directly benefit the overall performance. By analyzing the mainstream applications running on RISC-V, we observed that for the basic RISC-V instructions there is still quite some room for improvement in memory access related instructions.
First, we support register + register addressing mode, and support indexed load and store instructions. This type of instruction extension reduces the usage of the registers for calculation and reduces the number of instructions for address generation, thereby effectively accelerating the data access of a loop body. Second, unsigned extension during address generation is supported. Otherwise, the basic instruction set does not support direct unsigned extension from 32-bit data to 64-bit data, resulting in too many shift instructions.
I'm not certain if they break out the results by individual optimization, but in Fig. 20 in the paper it looks like all their tweaks add up to a 20% boost over the standard RISC-V ISA. Pretty huge.
>I'm not certain if they break out the results by individual optimization
They don't, so it's not clear where the 20% comes from. They're using a compiler that optimizes for their microarchitecture, which might account for a lot of that. As for the mention of "extensions", it's not even clear to me whether they mean official RISC-V extensions such as IMAFD or custom extensions.