Many people predict RISC-V to be mostly for IoT but I hope they will really push forward high performance implementation. Boom will get industrial support from Esperanto to push it to be a very high single thread performance core.
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.
Many people predict RISC-V to be mostly for IoT but I hope they will really push forward high performance implementation.
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 reason is that's a much easier and cheaper goal than competing with high-performance chips. On top of that, it might have an advantage if done royalty-free. There's one last possibility where FOSS IP built by the CompSci folks might be strung together into SoC's competing with microcontroller products with a NRE reduction by work already done.
> because it turns out that getting high performance from an ISA with only simple and relatively large instructions is actually rather difficult
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.
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.
The "official" response is that everything will be fine because the simpler instructions will be fused together automatically by high-performance CPUs. (The technique is called macro-op fusion). In fact there was a talk last year by Chris Celio (same person as in this video) on the subject:
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.
because the simpler instructions will be fused together automatically by high-performance CPUs
...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.
> 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.
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 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...
Yes, and for Ice Lake they're introducing the yes-this-time-we-really-mean-it-fast-rep-mov, er, "fast short rep movs". Time will tell whether it beats a software implementation.
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.
Risc-V, 64 bit w/ compressed instructions (strict subset of 32 bit instrs, freely intermix-able) is beating x86_64 right now in static and dynamic code size without vector extensions or anything fancy. With a few simple macro-op fusion pairs, it also comes right up to x86_64 in dynamic uOp count.
MIPS was a fairly early and ‘fundamentalist’ implementation that actually held its own for quite a long while in a very competitive segment of the market (microprocessors for high-end Silicon Graphics machines competing with other UNIX workstations). It had nowhere near the constant level of investment in R&D that Intel’s x86 (and other architectures, including other RISC workstation chips) enjoyed. So it's not entirely fair to point it out as being an abject failure that got relegated to the dustbin of history and is relegated to lowest of the low applications (embedded processors for commodity hardware).
This is the flip side of the (equally wrong) arguments that we still hear about how x86 is doomed because of its needlessly complicated ISA.
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).
Well, there are some things that the ISA impacts, most notably the translation overhead (modern day x86 "CISC" implementations are really essentially RISC processors with a translation layer over it). Jim Keller, who's been on both sides estimates that fully developed RISC ISAs should be about ~15-20% more efficient than their x86 counterparts.
That seems, let's just say awfully generous considering that we're well into the End of Silicon Scaling at this point and no such advantage has been seen yet. But whatever. The point isn't to say you can't design a bad ISA that would have performance impact, but that arguing about ISA as if it were a core driver of processor performance is dumb.
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!
I don't know anything about chip design. How far away is this chip from competing with Intel Core i7 or Amd Ryzen 7s?
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?
23 comments
[ 3.7 ms ] story [ 53.0 ms ] threadWe 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.
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.
See: https://www.youtube.com/watch?v=Ii_pEXKKYUg
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...
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.
https://arxiv.org/pdf/1607.02318.pdf
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!
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?