4 ms·

It probably was born as a practical academic experiment. It will be/has been used as an appealing alternative to cortex microcontrollers that are embedded in S

It probably was born as a practical academic experiment. It will be/has been used as an appealing alternative to cortex microcontrollers that are embedded in SoCs, storage devices, and add-in cards. But there's real commercial work trying to scale it up to bigger workloads too. I think these products are pretty early stage. I think Google is reluctant to push for Android support for a RISC-V applications processor. The nature of the different ISA extensions would mean that they would need to bet on the set of extensions that should be embraced (or a bunch of work to do some 'fat' binaries - or maybe 'obese' if there's a lot of supported combos). Regardless of Android's fate, yes, you can buy a RISC-V board that will boot linux. That's a pretty good bellwether for 'real applications'. But the performance likely pales in comparison with modern ARM or x86_64 alternatives. EDIT: see SiFive's "HiFive Unmatched" [1] for an example - DDR4, gigabit ethernet, 8 lanes of PCIe g3. It wouldn't surprise me if that's one of the best performing generally available RISC-V systems. [1] https://www.crowdsupply.com/sifive/hifive-unmatched https://www.crowdsupply.com/sifive/hifive-unmatched

saagarjha 6y ago
You could also alter behavior at runtime based on detected features…
- wyldfire 6y ago
  Sure, but that's not the hard bit. The toolchains that I've seen so far all generate code for a static set of RISC-V extensions and that set of extensions become the target platform's identity. Sort of like we've seen variations like 'armhf+gnueabi' before, except with RISC-V several of these 'extensions' are pretty much mandatory to get performance parity. The resolution of these ISA extensions is much higher than other architectures. That's part of the appeal, for sure. You can design a Just Right RISC-V without wasting any power or area supporting features you don't need. But until or unless the extensions stabilize to a canonical popular set (maybe this has already happened, or is happening soon), I wonder if the extension soup will cause some to be hesitant to adopt. Whatever hesitancy I am imagining is not holding back some super swift progress on all kinds of awesome RISC-V stuff.
  - sanxiyn 6y ago
    > But until or unless the extensions stabilize to a canonical popular set (maybe this has already happened, or is happening soon) It already happened. The set is RV64GC.
    - FullyFunctional 6y ago
      And that happened YEARS ago.
  - brucehoult 6y ago
    When you configure RISC-V gcc you tell it what default set of extensions you want it to use, but you can always tell it a different set with -march. I think that can't even be disabled. It may be that the toolchains you've seen were built with only one set of libraries. If you specify --enable-multilib when you build the toolchain then libraries for a dozen or so common combinations of extensions are built. If you're doing something embedded then you can build precisely the core and toolchain you want. If you're doing an OS for packaged software then you'll specify one (or a very small number) of combinations of extensions. Linux distributions such as Debian and Fedora decided on RV64GC a few years ago already. By the end of this year the B and V extensions (and a few smaller ones) should be ratified and the Linux distros will make a second set of supported extensions.
partingshots 6y ago
Check out - https://github.com/google/riscv-dv https://github.com/google/riscv-dv There’s pretty strong support for RISC-V and open source hardware in general at Google. Are they doing it to try and capitalize / control the market? Somewhat. But I don’t see it as necessarily a bad thing. The ecosystem benefits from it ultimately which is my primary concern.
- wyldfire 6y ago
  Oh yeah I'm sure Google in general is a fan just like all the other companies. But at some point in the (distant?) future, we will see Android phones and apps with RISC-V apps processors. Specifically the impact to android developers is what I'm curious about -- that's the challenge that google has to balance. Today there's support for x86_64 and arm, do they want to add the burden of rv64gc?
brucehoult 6y ago
The HiFive Unmatched will certainly be the best performing freely available RISC-V PC for the moment. Alibaba's XT910 might be similar but so far they're only using it internally. The U74 cores in the Unmatched are very similar uarch to the ARM A55 (as found in boards such as the Odroid C4) minus NEON. That's a good step better than the A53 found in the Raspberry Pi 3, but not as good as the out-of-order A72 in the Pi 4. Overall performance on many tasks may be similar to or even better than the Pi 4 as while the CPU cores are slightly worse the RAM and I/O are better, with the Unmatched having 16 GB DDR4, an M.2 slot for SSD, and PCIe for a real graphics card (SiFive demonstrates it with a Radeon RX 580). Obviously it's not price-competitive with a Pi at this point, as it's still low volume. The best RISC-V cores are around 5 or 6 years behind ARM in performance, but catching up. SiFive claims A72 equivalence for the U84 out of order core they announced 14 months ago (which will probably start to be available in silicon around the end of 2021) and AliBaba claims A73 equivalence for the XT910. Obviously no one has an Apple M1 equivalent RISC-V core at this point, but neither do ARM's customers.

saagarjha 6y ago

You could also alter behavior at runtime based on detected features…

wyldfire 6y ago
Sure, but that's not the hard bit. The toolchains that I've seen so far all generate code for a static set of RISC-V extensions and that set of extensions become the target platform's identity. Sort of like we've seen variations like 'armhf+gnueabi' before, except with RISC-V several of these 'extensions' are pretty much mandatory to get performance parity. The resolution of these ISA extensions is much higher than other architectures. That's part of the appeal, for sure. You can design a Just Right RISC-V without wasting any power or area supporting features you don't need. But until or unless the extensions stabilize to a canonical popular set (maybe this has already happened, or is happening soon), I wonder if the extension soup will cause some to be hesitant to adopt. Whatever hesitancy I am imagining is not holding back some super swift progress on all kinds of awesome RISC-V stuff.
- sanxiyn 6y ago
  > But until or unless the extensions stabilize to a canonical popular set (maybe this has already happened, or is happening soon) It already happened. The set is RV64GC.
  - FullyFunctional 6y ago
    And that happened YEARS ago.
- brucehoult 6y ago
  When you configure RISC-V gcc you tell it what default set of extensions you want it to use, but you can always tell it a different set with -march. I think that can't even be disabled. It may be that the toolchains you've seen were built with only one set of libraries. If you specify --enable-multilib when you build the toolchain then libraries for a dozen or so common combinations of extensions are built. If you're doing something embedded then you can build precisely the core and toolchain you want. If you're doing an OS for packaged software then you'll specify one (or a very small number) of combinations of extensions. Linux distributions such as Debian and Fedora decided on RV64GC a few years ago already. By the end of this year the B and V extensions (and a few smaller ones) should be ratified and the Linux distros will make a second set of supported extensions.

partingshots 6y ago

Check out - https://github.com/google/riscv-dv https://github.com/google/riscv-dv There’s pretty strong support for RISC-V and open source hardware in general at Google. Are they doing it to try and capitalize / control the market? Somewhat. But I don’t see it as necessarily a bad thing. The ecosystem benefits from it ultimately which is my primary concern.

wyldfire 6y ago
Oh yeah I'm sure Google in general is a fan just like all the other companies. But at some point in the (distant?) future, we will see Android phones and apps with RISC-V apps processors. Specifically the impact to android developers is what I'm curious about -- that's the challenge that google has to balance. Today there's support for x86_64 and arm, do they want to add the burden of rv64gc?

brucehoult 6y ago

The HiFive Unmatched will certainly be the best performing freely available RISC-V PC for the moment. Alibaba's XT910 might be similar but so far they're only using it internally. The U74 cores in the Unmatched are very similar uarch to the ARM A55 (as found in boards such as the Odroid C4) minus NEON. That's a good step better than the A53 found in the Raspberry Pi 3, but not as good as the out-of-order A72 in the Pi 4. Overall performance on many tasks may be similar to or even better than the Pi 4 as while the CPU cores are slightly worse the RAM and I/O are better, with the Unmatched having 16 GB DDR4, an M.2 slot for SSD, and PCIe for a real graphics card (SiFive demonstrates it with a Radeon RX 580). Obviously it's not price-competitive with a Pi at this point, as it's still low volume. The best RISC-V cores are around 5 or 6 years behind ARM in performance, but catching up. SiFive claims A72 equivalence for the U84 out of order core they announced 14 months ago (which will probably start to be available in silicon around the end of 2021) and AliBaba claims A73 equivalence for the XT910. Obviously no one has an Apple M1 equivalent RISC-V core at this point, but neither do ARM's customers.