RISC-V is amazing as what it is, but it isn't a competitor for high-end performance. It's simply not designed for that.
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.
As a practical counterexample to that FUD, it is also the ISA chosen by the Barcelona Super-computing Center EuroHPC[1] to design a new high performance CPU for future supercomputers.
[0]https://riscv.org/technical/specifications/
[1]https://www.bsc.es/news/bsc-news/bsc-working-towards-the-fir...
I know virtually nothing about the internals, but that‘s also what people said about ARM.
> If X86 still competes I see no reason why RISC-V can't also
First RISC-V needs to catch up with the 40 years of x86 improvements that kicked out SPARC, Cray, SGI and others from high-end performace systems.
I'd suspect an ISA designed in the last few years with performance in mind (even if not a priority), wouldn't take as long to get to where the industry is now, but it's still a lot of years of focused effort required, and we'll see.
I don't have a horse in the race, except that I do like my experience to not evaporate; and I sincerly hope real mode segmented address edge cases aren't something I'd need to relearn on another ISA even though they're still (barely) relevant on x86 in early boot.
Saying X86 is 40 years work is also kind of stupid, as a huge amount of the ISA dead weight, and high performance implementations have their roots much earlier than that (e.g. Intel have tried to move on at least once and ended up coming back to the OOO superscalar paradigm).
1. Already ported.
2. Not dependent on modern performance, and thus well served by emulation.
Just shows the power of an establed ISA (all the software that runs on top of it) and how solid ARM's business model is.
The ISA is an interface, and as such may not be copyrightable or even patentable. Even if it was, we've had various interoperability exceptions, and one does need an ARM ISA to run a program compiled for ARM.
Besides, as far as I know ARM doesn't just license the ISA. It licenses cores. There's a good chance that if you make your own cores to implement an ARM ISA, you wouldn't have to pay any fee. You may however have to get around trademark, and not call your CPUs "ARM CPUs". Though I suspect "ARM compatible" would work perfectly (just like "IBM compatible" worked with third party PC vendors).
The terms are secret, but basically yes, AMD had access to 386? designs and what not as part of IBMs second source requirements with Intel, but Amd486 and up designs were AMD original with instruction sets under license from Intel, although the licenses were set up after release under litigation.
> Does Intel pay AMD a fee for using their 64 bit extensions?
Yes / sort of. Use of the AMD64 extentions was negotiated under the broad cross licensing between the two companies.
> Does anybody pay the inventor of the SSE and AVX instruction sets?
Do the persons involved get royalties? I'd guess not, but who knows. Would you have to pay more to get a license for them, almost certainly.
You'll note there's been a lot fewer x86 processor designs not from the big two over the past many years than there were in the late 90s. Some of that is because 'RISC is going to change everything', but a lot of it is becsause nobody can get an x86 license.
> Does anybody pays Nintendo for deploying emulators?
I don't think so. Patents are too old, and there's not a whole lot of non-Nintendo emulation in the commercial market (but I know Capcom has released some collections, of Megaman games, etc). If those types of releases started including systems with system roms, then you would start having copyright claims.
Nintendo has never seriously impeded system emulation; there's just no case to be made. ROM distribution is clear copyright violation though, of course.
[0] https://riscv.org/technical/specifications/
(start with chapter 1 of the unprivileged spec)