RISC-V Is Sloooow

rbanffy

Don't blame the ISA - blame the silicon implementations AND the software with no architecture-specific optimisations. RISC-V will get there, eventually. I remember that ARM started as a speed demon with conscious power consumption, then was surpassed by x86s and PPCs on desktops and moved to embedded, where it shone by being very frugal with power, only to now be leaving the embedded space with implementations optimised for speed more than power.

leni536

Is cross compilation out of the question?

lifis

Or they could fix cross compilation and then compile it on a normal x86_64 server

IshKebab

Yeah it's a few years behind ARM, but not that many. Imagine trying to compile this on ARM 10 years ago. It would be similarly painful.

rbalint

If the builds are slow, build accelerators can help a lot. Ccache would work for sure and there is also firebuild, that can accelerate the linker phase and many other tools in builds.

brcmthrowaway

Why is it slow? I thought we have Rivos chips

Joel_Mckay

Any new hardware lags in compiler optimizations. i. llvm presentation can thrash caches if setup wrong (given the plethora of RISC-V fragmented versions, most compilers won't cover every vanity silicon.) ii. gcc is also "slow" in general, but is predictable/reliable iii. emulation is always slower than kvm in qemu It may seem silly, but I'd try a gcc build with -O0 flag, and a toy unit test with -S to see if the ASM is actually foobar. One may have to force the -mtune=boom flag to narrow your search. Best regards =3

Levitating

This is why felix has been building the risc-v archlinux repositories[1] using the Milk-V Pioneer. I think the ban of SOPHGO is part to blame for the slow development.[2] They had the most performant and interesting SOCs. I had a bunch of pre-orders for the Milk-V Oasis before it was cancelled. It was supposed to come out a while ago, using the SG2380, supposedly much more performant than the Milk-V Titan mentioned in the article (which still isn't out). It was also SOPHGO's SOCs that powered the crazy cheap/performant/versatile Milk-V DUO boards. They have the ability to switch ARM/RISC-V architecture. [1]: https://archriscv.felixc.at/ [2]: https://www.tomshardware.com/tech-industry/artificial-intell...

andrepd

There's zero mention of hardware specs or cost beyond architecture and core counts... What is the purpose of this post? Anyway, it's hardly surprising that a young ISA with not a 1/1000th of the investment of x86 or ARM has slower chips than them x)

sltkr

Are you sure you are comparing apples with apples here? The fact that i686 is 14% faster than x86_64 is a little suspicious, because usually the same software runs _faster_ on x86_64 (despite the increased memory use) thanks to a larger register set, an optimized ABI, and more vector instructions. Of course, if you are compiling an i686 binary on i686, and an x86_64 binary on x86_64, then the compilers aren't really doing the same work, since their output is different. I'm not a compiler expert, but I could imagine that compiling x86_64 binaries is intrinsically slower than for i686 for a variety of reasons. For example, x86_64 is mostly a superset of i686, so a compiler has way more instructions to consider, including potential optimizations using e.g. SIMD instructions that don't exist on i686 at all. Or a compiler might assume a larger instruction cache size, by default, and do more unrolling or inlining when compiling for x86_64. And so on. In that case, compiling on x86_64 is slower not because the hardware is bad but because the compiler does more work. Perhaps something similar is happening on RISC-V.

srott

Couldn’t be caused by a slower compiler? Fe. What would be a difference when cross compiling same code to aarch64 vs risc-v?

yogthos

there are projects for making high performance RISC-V chips like this one https://github.com/OpenXiangShan/XiangShan

kashyapc

Arm had 40 years to be where it is today. RISC-V is 15 years old. Some more patience is warranted. Assuming they will keep their word, later this year Tenstorrent is supposed to ship their RVA23-based server development platform[1]. They announced[2] it at the last year's NA RISC-V Summit. Let's see. The ball is in the court of hardware vendors to cook some high-end silicon. [1] https://tenstorrent.com/ip/risc-v-cpu [2] https://static.sched.com/hosted_files/riscvsummit2025/e2/Unl...

mrbluecoat

> Random mumblings of ARM developer ... RISC-V is sloooow Old news. See also: > Random mumblings of x86_64 developer ... ARM is sloooow

saghm

If I'm reading their chart right, they have barely half as much memory for their RISC-V machine compared to any of the others? I don't know enough to know whether it's actually bottlenecked by memory, but it's a bit odd to claim it's slower, give those numbers, and not say anything about it. I'd hope they ruled that out as the source of the discrepancy, but it's hard to tell without confirmation.

mkj

Does that page even say which RISC-V CPUs are being used that are slow? I couldn't see it, which seems a bit of pointless complaining.

AceJohnny2

There was a Mastodon post some time back (~1y?) where someone realized that the fastest RISC-V hardware they could get was still slower than running it on QEMU. That's not how it usually works :\ RISC-V is certainly spreading across niches, but performant computing is not one of them. Edit: lol the author mentions the same! Perhaps they were the source of the original Mastodon post I'm thinking of.

echoangle

Is there a simple explanation why RISC-V software has to be built on a RISC-V system? Why is it so hard for compilers to compile for a different architecture? The general structure of the target architecture lives inside the compiler code and isn’t generated by introspecting the current system, right?