6 ms·

Boom v2: Open-source out-of-order RISC-V core [video]

75 points by nickik 9y ago

nickik 9y ago
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.
- userbinator 9y ago
  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.
  - nickpsecurity 9y ago
    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.
  - nickik 9y ago
    > 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. See: https://www.youtube.com/watch?v=Ii_pEXKKYUg https://www.youtube.com/watch?v=Ii_pEXKKYUg
    - userbinator 9y ago
      Even if you do it for both the MIPS/RISC-V will run with lower energy and less area. http://www.extremetech.com/wp-content/uploads/2014/08/AverageEnergy.png 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-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient https://www.extremetech.com/extreme/188396-the-final-isa-sho...
      - snvzz 9y ago
        Maybe try a Pentium 4. That's x86 too (!).
  - rwmj 9y ago
    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: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf 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.
    - nickik 9y ago
      You don't even need the fuse. That's just an optimization. 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.
    - jabl 9y ago
      FWIW, the paper, with more details than the slides, is https://arxiv.org/abs/1607.02318 https://arxiv.org/abs/1607.02318
    - userbinator 9y ago
      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.
  - qubex 9y ago
    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).
  - ajross 9y ago
    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).
    - deepnotderp 9y ago
      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.
      - ajross 9y ago
        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!
      - phkahler 9y ago
        Do you have a reference for that Jim Keller estimate? BTW he's at nVidia and they have a solid interest in risc-v ;-)
        deepnotderp 9y ago
        He's at Tesla after being at AMD and Apple, I don't think he was ever at nvidia.
robert_foss 9y ago
This video goes into the depths of CPU design, but is quite easy to follow. Highly recommended!
us589 9y ago
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?

75 points by nickik 9y ago

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.

userbinator 9y ago
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.
- nickpsecurity 9y ago
  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.
- nickik 9y ago
  > 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. See: https://www.youtube.com/watch?v=Ii_pEXKKYUg https://www.youtube.com/watch?v=Ii_pEXKKYUg
  - userbinator 9y ago
    Even if you do it for both the MIPS/RISC-V will run with lower energy and less area. http://www.extremetech.com/wp-content/uploads/2014/08/AverageEnergy.png 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-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient https://www.extremetech.com/extreme/188396-the-final-isa-sho...
    - snvzz 9y ago
      Maybe try a Pentium 4. That's x86 too (!).
- rwmj 9y ago
  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: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf 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.
  - nickik 9y ago
    You don't even need the fuse. That's just an optimization. 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.
  - jabl 9y ago
    FWIW, the paper, with more details than the slides, is https://arxiv.org/abs/1607.02318 https://arxiv.org/abs/1607.02318
  - userbinator 9y ago
    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.
- qubex 9y ago
  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).
- ajross 9y ago
  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).
  - deepnotderp 9y ago
    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.
    - ajross 9y ago
      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!
    - phkahler 9y ago
      Do you have a reference for that Jim Keller estimate? BTW he's at nVidia and they have a solid interest in risc-v ;-)
      - deepnotderp 9y ago
        He's at Tesla after being at AMD and Apple, I don't think he was ever at nvidia.

robert_foss 9y ago

This video goes into the depths of CPU design, but is quite easy to follow. Highly recommended!

us589 9y ago

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?