4 ms·

If we want this to go anywhere, not just super computing, the first step is to get devices, useful devices, in the hands of enthusiast. That means funding proje

If we want this to go anywhere, not just super computing, the first step is to get devices, useful devices, in the hands of enthusiast. That means funding projects similar to the Raspberry Pi, but for RISC-V, and perhaps mini-itx boards. We need these cheap-ish computers in the hands of people who will port software to the platform. Without a good selection of ready to go software, the hardware is pretty irrelevant.

deleted 2y ago
[deleted]
markus_zhang 2y ago
Yup. We need hobbyists to bootstrap the process. Preferably in schools too. I know there is Orange Pi Riscv but maybe there are other cheap hardwares.
tux1968 2y ago
https://milkv.io/duo https://milkv.io/duo Gives you something to play around with, very inexpensively. But really, virtual machines may be preferable; at least to get started.
- hulitu 2y ago
  > But really, virtual machines may be preferable; at least to get started. And what shall one emulate in a VM ? A nonexisting physical processor ? /s
  - tux1968 2y ago
    https://www.qemu.org/docs/master/system/target-riscv.html https://www.qemu.org/docs/master/system/target-riscv.html
  - XorNot 2y ago
    Wouldn't this be ideal though? Emulate the processor we'd like to have and work backwards to see if it can be built?
  - Yoric 2y ago
    I'm almost certain that this is exactly how it works in processor design. You start building your compiler before the processor is finished, and test it with the emulator. At least, in quantum computing, that's how it works.
  - zamadatix 2y ago
    "Virtual Machine" doesn't place restrictions on whether the guest's CPU is emulated or not despite "CPU virtualization" explicitly meaning "the instructions are not emulated". It's a bit wonky and I wish the terms had some more separation for clarifying exactly this case.
ndsipa_pomu 2y ago
I posted this link to HN not very long ago: https://liliputing.com/orange-pi-rv2-is-a-single-board-pc-with-an-8-core-risc-v-processor/ https://liliputing.com/orange-pi-rv2-is-a-single-board-pc-wi... Discussion here: https://news.ycombinator.com/item?id=43309376 https://news.ycombinator.com/item?id=43309376
Palomides 2y ago
98% of debian packages build for riscv already, and a variety of pi like boards are available
anotherhue 2y ago
The framework main board is surely that? https://frame.work/products/deep-computing-risc-v-mainboard https://frame.work/products/deep-computing-risc-v-mainboard
- littlestymaar 2y ago
  Awesome, thanks for sharing that.
- camel-cdr 2y ago
  No it's not. For HPC good software support for the vector extension is basically everything that matters, and the framework main board doesn't support that extension. I would currently recommend the BananaPI BPI-F3 or the OrangePI RV2 for that purpose, as they both have the same SpacemiT X60 cores, which support the vector extension. Sadly there are currently only in-order cores with RVV support available. Getting a cheap out-of-order implementation is the next most important thing for improving software support. Tenstorrent has announced they will release a 8x Ascalon devboard and laptop next year: https://youtu.be/ttQtC1dQqwo?t=1035 https://youtu.be/ttQtC1dQqwo?t=1035
  - knorker 2y ago
    Thank you! I've been waiting for a viable RVV board for a long time. Just ordered the OrangePi RV2. This unblocks me properly working to optimize for vector support in software. OOO and even wider RVV registers will then automatically speed things up, without even a recompile. Yes, I know I could use qemu, but it's not the same. I feel like this is what unblocks me on the software side.
    - camel-cdr 2y ago
      > OOO and even wider RVV registers will then automatically speed things up, without even a recompile. The problem is that there are some things in RVV where it's unclear how they will perform on high perf OoO cores: * general choice of LMUL: on in-order cores it's clear that maximizing LMUL without spilling is the best approach, for OoO this isn't clear. * How will LMUL>1 vrgather and vcompress perform? * How high is the impact of vsetvli instructions? Is it worth trying to move them outside of loops whenever possible, or is the impact minimal like in the current in-order implementations. * What is the overhead of using .vx instruction variants, is there additional cost involved in moving between GPRs and vector registers? * Is there additional overhead when reinterpreting vector masks? * What performance can we expect from the more complex load/stores, especially the segmented ones. The LLVM scheduling models give some insight: * SiFive P670: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVSchedSiFiveP600.td https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ... * Tenstorrent Ascalon: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVSchedTTAscalonD8.td https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ... (still missing the vector part, but there is supposed to be a PR in the near future) I'm trying to collect as much info on hardware as I can: https://camel-cdr.github.io/rvv-bench-results/index.html https://camel-cdr.github.io/rvv-bench-results/index.html
marssaxman 2y ago
Such things have existed for several years already! Here are some examples: https://sifive.com/boards/hifive-premier-p550 https://sifive.com/boards/hifive1-rev-b https://www.beagleboard.org/boards/beaglev-fire https://starfivetech.com/en/site/boards https://milkv.io/docs/duo/getting-started/duo256m There is even a Raspberry Pi model which includes two RISC-V cores alongside its ARM cores: https://www.raspberrypi.com/products/rp2350/
- Levitating 2y ago
  Milk-V has much more than the duo. I have a few of their products and they're very cool! The biggest problem with them is software. Many boards only have buildroot SDKs or niche and outdated. Fedora related images. Though if you're experienced you can port your own linux distributions to these boards.
  - nine_k 2y ago
    But Duo is a device in the form factor of Arduino Nano that can run actual Linux (the 256MB RAM version at least). It's quite a leap.

deleted 2y ago

[deleted]

markus_zhang 2y ago

Yup. We need hobbyists to bootstrap the process. Preferably in schools too. I know there is Orange Pi Riscv but maybe there are other cheap hardwares.

tux1968 2y ago

https://milkv.io/duo https://milkv.io/duo Gives you something to play around with, very inexpensively. But really, virtual machines may be preferable; at least to get started.

hulitu 2y ago
> But really, virtual machines may be preferable; at least to get started. And what shall one emulate in a VM ? A nonexisting physical processor ? /s
- tux1968 2y ago
  https://www.qemu.org/docs/master/system/target-riscv.html https://www.qemu.org/docs/master/system/target-riscv.html
- XorNot 2y ago
  Wouldn't this be ideal though? Emulate the processor we'd like to have and work backwards to see if it can be built?
- Yoric 2y ago
  I'm almost certain that this is exactly how it works in processor design. You start building your compiler before the processor is finished, and test it with the emulator. At least, in quantum computing, that's how it works.
- zamadatix 2y ago
  "Virtual Machine" doesn't place restrictions on whether the guest's CPU is emulated or not despite "CPU virtualization" explicitly meaning "the instructions are not emulated". It's a bit wonky and I wish the terms had some more separation for clarifying exactly this case.

ndsipa_pomu 2y ago

I posted this link to HN not very long ago: https://liliputing.com/orange-pi-rv2-is-a-single-board-pc-with-an-8-core-risc-v-processor/ https://liliputing.com/orange-pi-rv2-is-a-single-board-pc-wi... Discussion here: https://news.ycombinator.com/item?id=43309376 https://news.ycombinator.com/item?id=43309376

Palomides 2y ago

98% of debian packages build for riscv already, and a variety of pi like boards are available

anotherhue 2y ago

The framework main board is surely that? https://frame.work/products/deep-computing-risc-v-mainboard https://frame.work/products/deep-computing-risc-v-mainboard

littlestymaar 2y ago
Awesome, thanks for sharing that.
camel-cdr 2y ago
No it's not. For HPC good software support for the vector extension is basically everything that matters, and the framework main board doesn't support that extension. I would currently recommend the BananaPI BPI-F3 or the OrangePI RV2 for that purpose, as they both have the same SpacemiT X60 cores, which support the vector extension. Sadly there are currently only in-order cores with RVV support available. Getting a cheap out-of-order implementation is the next most important thing for improving software support. Tenstorrent has announced they will release a 8x Ascalon devboard and laptop next year: https://youtu.be/ttQtC1dQqwo?t=1035 https://youtu.be/ttQtC1dQqwo?t=1035
- knorker 2y ago
  Thank you! I've been waiting for a viable RVV board for a long time. Just ordered the OrangePi RV2. This unblocks me properly working to optimize for vector support in software. OOO and even wider RVV registers will then automatically speed things up, without even a recompile. Yes, I know I could use qemu, but it's not the same. I feel like this is what unblocks me on the software side.
  - camel-cdr 2y ago
    > OOO and even wider RVV registers will then automatically speed things up, without even a recompile. The problem is that there are some things in RVV where it's unclear how they will perform on high perf OoO cores: * general choice of LMUL: on in-order cores it's clear that maximizing LMUL without spilling is the best approach, for OoO this isn't clear. * How will LMUL>1 vrgather and vcompress perform? * How high is the impact of vsetvli instructions? Is it worth trying to move them outside of loops whenever possible, or is the impact minimal like in the current in-order implementations. * What is the overhead of using .vx instruction variants, is there additional cost involved in moving between GPRs and vector registers? * Is there additional overhead when reinterpreting vector masks? * What performance can we expect from the more complex load/stores, especially the segmented ones. The LLVM scheduling models give some insight: * SiFive P670: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVSchedSiFiveP600.td https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ... * Tenstorrent Ascalon: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVSchedTTAscalonD8.td https://github.com/llvm/llvm-project/blob/main/llvm/lib/Targ... (still missing the vector part, but there is supposed to be a PR in the near future) I'm trying to collect as much info on hardware as I can: https://camel-cdr.github.io/rvv-bench-results/index.html https://camel-cdr.github.io/rvv-bench-results/index.html

marssaxman 2y ago

Such things have existed for several years already! Here are some examples: https://sifive.com/boards/hifive-premier-p550 https://sifive.com/boards/hifive1-rev-b https://www.beagleboard.org/boards/beaglev-fire https://starfivetech.com/en/site/boards https://milkv.io/docs/duo/getting-started/duo256m There is even a Raspberry Pi model which includes two RISC-V cores alongside its ARM cores: https://www.raspberrypi.com/products/rp2350/

Levitating 2y ago
Milk-V has much more than the duo. I have a few of their products and they're very cool! The biggest problem with them is software. Many boards only have buildroot SDKs or niche and outdated. Fedora related images. Though if you're experienced you can port your own linux distributions to these boards.
- nine_k 2y ago
  But Duo is a device in the form factor of Arduino Nano that can run actual Linux (the 256MB RAM version at least). It's quite a leap.