11 hours ago
I’m a fan of this, although I’m concerned about the security/trust model: using a third-party CI orchestrator on top of GHA means trusting them with all of your secrets, potentially sensitive logs, etc. Those concerns are somewhat lessened in the context of public repos, but even public repos contain nontrivial workflows that use configured secrets.
10 hours ago
My experience with RISC-V so far is that the chips are not much faster than QEMU emulation. In other words, it's very slow.
10 hours ago
That has been the case so far but is changing this year.
The SpacemiT K3 is faster than QEMU. Much faster chips are expected to release over the next few months.
I mean things like the Milk-V Pioneer were already faster but expensive.
One thing that has been frustrating about RISC-V is that many companies close to releasing decent chips have been bought and then those chips never appear (Ventana, Rivos, etc). That and US sanctions (eg. Sophgo SG2380).
4 hours ago
One thing I observed is that RVV code is usually slower in QEMU
6 hours ago
Some of that could be related to the ISA but I'm hoping that it's just the fact that the current implementations aren't mature enough.
The vast majority of the ecosystem seems to be focused on uCs until very recently. So it'll take time for the applications processors to be competitive.
5 hours ago
The RISC-V ISA can be fast.
Tenstorrent Ascalon, expected later this year, is expected to be AMD Ryzen 5 speeds. Tenstorrent hopes to achieve Apple Silicon speeds in a few years.
The SpacemiT K3 is about half as fast as Ascalon and available in April. K3 is 3-4 times faster than the K1 (previous generation).
This should give you an idea about how fast RISC-V is improving.
7 hours ago
Same experience here.
At least for SBCs, I’ve bought a few orange pi rv2s and r2s to use as builder nodes, and in some cases they are slower than the same thing running in qemu w/buildx or just qemu
10 hours ago
Oftentimes slow is fine, when the work is parallel and the hardware is cheap
5 hours ago
RISC-V microcontrollers are inexpensive but “application” processors will be expensive until volumes increase.
Performance will get “good enough” over the next 2 years. Prices will drop after that.
5 hours ago
That the "good enough" SoCs will be arriving "over the next 2 years" is what the RISC-V advocates have told us for quite a few years now.
9 hours ago
which, sadly, isnt the case right now
8 hours ago
It is the case for embedded microcontrollers. An ESP32-C series is about as cheap as you can get a WiFi controller, and it includes one or more RISC-V cores that can run custom software. The Raspberry Pi Pico and Milk-V Duo are both a few dollars and include both ARM and RISC-V view. with all but the cheapest Duo able to run Linux.
4 hours ago
The arrival of the first RVA23 chips, which is expected next month, will change the status quo.
Besides RVA23 compliance, these are dramatically faster than earlier chips, enough for most people's everyday computing needs i.e. web browsing, video decoding and such. K3 got close to rpi5 per-core performance, but with more cores, better peripherals, and 32GB RAM possible, although unfortunately current RAM prices are no good.
And it'll only get better from there, as other, much faster, RVA23 chips like Tenstorrent Alastor ship later this year.
3 hours ago
The security concern raised here is worth thinking through. Third-party CI runners see your workflow environment — that's the actual trust boundary.
For public repos (the primary target here), the bigger practical concern is usually the opposite: your workflows fire webhooks to external systems and you have no visibility into what those systems actually received. This is especially true when integrating notification or deployment hooks that run after a successful test suite. The architecture step (source → RISC-V runner → build artifact → deployment hook) adds another hop where payloads can be malformed or swallowed silently.
The Linux Foundation backing does address the trust question well. RISE's membership list reads like a who's who of RISC-V commercial stakeholders — the incentive structure is to build trust in the ecosystem, not undermine it.
10 hours ago
Sadly still on quite old hardware, with no RVV. Hopefully scaleway will have some newer servers in the future and this can be simply updated to the new devices.
9 hours ago
You can get RVV instances from Saleway.
9 hours ago
Oh, cool, I didn't see them on the website. (https://labs.scaleway.com/en/em-rv1/)
11 hours ago
Very good move. Hopefully GitHub won't ruin this with their CI charging changes.
9 hours ago
GitHub only :(
10 hours ago
..is this RVA23?
10 hours ago
Not yet
RV64GC (C910 cores)
11 hours ago
Perfect for snooping on other people’s projects. No one in their right mind would touch this. It’s cheaper to buy the board yourself.
10 hours ago
Yes, what a devious plan: give open source software projects a free CI service so you can... read their open source software code?
10 hours ago
diabolical
9 hours ago
devious
9 hours ago
duplicitous
11 hours ago
It seems to be a Linux Foundation project, my trust is implicit higher than what you're claiming. Why wouldn't you trust them?
It's also aimed at open-source projects, for free, with the intent to improve RISC-V support.
4 hours ago
Why would you trust anyone offering free candies?
11 hours ago
RISE is supported by many legit companies. Stealing is for sure not the intent.
The idea is to promote testing on RISC-V and to eliminate lack of hardware for being the reason not to. Obviously, low budget projects and Open Source are the primary targets. Commercial products can afford real RISC-V hardware.
This is who you are trusting: https://riseproject.dev/members/
11 hours ago
people better not be snooping on my public open source projects!