[mrweasel]

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.

[marssaxman]

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]

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]

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.

[anotherhue]

The framework main board is surely that?

https://frame.work/products/deep-computing-risc-v-mainboard

[camel-cdr]

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

[knorker]

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]

> 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/Targ...

* Tenstorrent Ascalon: 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

[littlestymaar]

Awesome, thanks for sharing that.

[ndsipa_pomu]

I posted this link to HN not very long ago: https://liliputing.com/orange-pi-rv2-is-a-single-board-pc-wi...

Discussion here: https://news.ycombinator.com/item?id=43309376

[tux1968]

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]

> 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]

https://www.qemu.org/docs/master/system/target-riscv.html

[zamadatix]

"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.

[Yoric]

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.

[XorNot]

Wouldn't this be ideal though? Emulate the processor we'd like to have and work backwards to see if it can be built?

[Palomides]

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

[markus_zhang]

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.