Boom v2: Open-source out-of-order RISC-V core [video]
youtube.com
youtube.com
We are really moving in a direction where it is possible to have a open software hardware stack running on your everyday working devices.
There will still be some third party IP and such but having an open source core (Rocket, Boom and others), SoC (LowRisc), firmware (coreboot/heads), kernel (linux) and userland (gnu, android) will be fantastic.
The third party IP can be replaced step by step with open source efforts from the open source community, the universities, government funds and business who want free IP.
I really hope we see and raspberry pi style computers soon and hopefully developer laptops in the next 1-2 years. Purism would maybe do something like that.
The reason for that prediction is simple: it's what happened to MIPS, which in its heyday got as much if not more hype than RISC-V. Advocates thought it would be the "architecture of the future" for everything from tiny embedded systems to high-performance supercomputers. Now, its popularity is only in the former, because it turns out that getting high performance from an ISA with only simple and relatively large instructions is actually rather difficult. You can add SIMD and other extensions to look competitive in specific benchmarks, but general-purpose code will still be behind compared to something like x86 or even ARM.
The simple truth is that the ISA just isn't a big deal. I mean, there are good and bad features of all of them, and sure, they have performance implications on the margins. But those effects are things that can be hidden behind e.g. a small constant factor on the "effective icache size". It's just not a big deal to translate external instructions into an internal format (either denser, and MIPS or RISC-V would need, or sparser, as Intel does with uOPs).
Stated less charitably: programmers like us like to argue about ISA because we understand that stuff and want to bike shed about something that makes us feel smart.
The real issues with CPU design happen elsewhere, as literally illustrated by the linked presentation!
https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu...
Also note that RISC-V has a standardized compressed instruction extension which is expected to be present on just about any high-performance 64 bit chip, and that makes the case for macro-op fusion more persuasive, since n x 16 bit instructions might be fused and still take the same space as a specialized CISC instruction.
I guess we won't really know until the hardware exists though.
Specially see: > RV64GC is 8% fewer instruction bytes than x86-64
Since RV64GC is stnadard in the Linux ABI there is no argument that ISA verbosity is a problem.
...but then the larger instructions will still take up cache space and fetch bandwidth, with the effects becoming even more significant with multiple cores.
since n x 16 bit instructions might be fused and still take the same space as a specialized CISC instruction.
As the saying goes, "In theory, there's no difference between theory and practice. In practice, there is." It's far easier to split a CISC instruction into uops, than to attempt to detect the possibly near-infinite combinations of RISC instructions that effectively do the same thing so that they can be fused together. It's like the CPU has to almost decompile the program, at runtime, to figure out what it's doing and how to do it more efficiently on the hardware...
Consider a round of AES, for example. Or for something simpler, a memory copy loop. On x86, the latter is 2 bytes (and has been since the 8086), and the former can be as small as 6 on the recent CPUs that have the AESNI extensions. Maybe RISC-V can do the former in 4, but how often are AES operations performed vs. bulk memory copying, and can RISC-V do the latter in 2? Those are the sorts of things which benchmarks often don't show very well --- I have no doubt RISC-V and ARM can (slightly) beat x86 in code density for vector operations and such specialised things, but in practice, everything else matters too --- sequential, general-purpose, perhaps somewhat branchy code.
I lived through the first RISC hype. This feels like a repeat.
Er, it's not like macro-op fusion is some theoretical thing that isn't proven in practice. x86 cpu's have done it for quite a while for CMP+JMP, and compilers optimize for it by not putting other instructions between the CMP and JMP. That is, macro fusion doesn't scan through some huge window of instructions, it only works for neighboring instructions.
If you want to know more, I recommend reading through the slides that the parent poster linked, and the article link I posted in a sibling comment.
> Consider a round of AES, for example.
FWIW, there is ongoing work to add a crypto extension to RISC-V, so this isn't really an argument for or against RISC-V per se.
> Or for something simpler, a memory copy loop. On x86, the latter is 2 bytes (and has been since the 8086)
REP MOV* is a good example of what's wrong with CISC. It gets you good instruction density, I grant you that, but it also slower than alternative implementations using, say unrolled loops and vector instructions. Look into a modern memcpy() implementation and prepare to be horrified. If it were that easy to make REP MOV fast, one would have thought that Intel with their near-unlimited budget would have made it so.
Look up "enhanced REP MOVS" (Ivy Bridge), and before that, "fast strings" (P6). It can copy entire cachelines at once and easily beats anything else except in tiny microbenchmarks where the negative effects of huge unrolled loops don't appear. In general, the historical performance of the string instructions is interesting and worth researching more...
But my point still stands, if you're developing a new ISA, does it really make sense to add dedicated string copy instructions, using opcode space, adding die area for microcode ROM's, design and verification costs etc., considering that even Intel with all their money can't make them an obvious win compared to a software implementation?
But yes, both for x86 and RISC architectures, it's probably unwise to optimize memcpy() implementations by staring at microbenchmarks that do nothing else than memcpy() of different sizes, thus ignoring the I$ pollution that a monster implementation causes.
That is not the reason. Its actually far easier to build a fast MISP or RISC-V Out-of-order CPU then it is a x86. Even if you do it for both the MIPS/RISC-V will run with lower energy and less area.
If you look at a ISA countsy you will see that MISP on 64 Bit is not that far behind x86 and RISC-V is actually ahead in instruction count specially when including the C extension that is in the standard for the Linux ABI.
http://www.extremetech.com/wp-content/uploads/2014/08/Averag...
That's a 4-way OoO MIPS with 64K L1D and 64K L1C, being far less energy-efficient than 2- and 3-way OoO and in-order(!) x86s and ARMs with half or less L1D and L1C. All results were scaled to 1GHz and 45nm, which already makes x86 look worse and the ARMs and MIPS better than they are in practice.
Full article: https://www.extremetech.com/extreme/188396-the-final-isa-sho...
Highly recommended!
Will it require hundreds of people and budget in the hundreds of millions of dollar? Or can small groups of researchers develop BOOM more until it can compete in the desktop market?