Red Hat developer Marcin Juszkiewicz is working on the RISC-V port of Fedora Linux, and after a few months of working on it, published a blog post about just how incredibly slow RISC-V seems to be. This is a real problem, as in Fedora, build results are only released once all architectures have completed their builds.
There is no point of going for inclusion with slow builders as this will make package maintainers complain. You see, in Fedora build results are released into repositories only when all architectures finish. And we had maintainers complaining about lack of speed of AArch64 builders in the past. Some developers may start excluding RISC-V architecture from their packages to not have to wait.
And any future builders need to be rackable and manageable like any other boring server (put in a rack, connect cables, install, do not touch any more). Because no one will go into a data centre to manually reboot an SBC-based builder.
Without systems fulfilling both requirements, we can not even plan for the RISC-V 64-bit architecture to became one of official, primary architectures in Fedora Linux.
↫ Marcin Juszkiewicz
RISC-V really seems to have hit some sort of ceiling over the past few years, with performance improvements stalling and no real performance-oriented chips and boards becoming available. Everybody seems to want RISC-V to succeed and become an architecture that can stand its own against x86 and Arm, but the way things are going, that just doesn’t seem likely any time soon. There’s always some magical unicorn chip or board just around the corner, but when you actually turn that corner, it’s just another slow SBC only marginally faster than the previous one.
Fedora is not the first distribution struggling with bringing RISC-V online. Chimera Linux faced a similar issue about a year ago, but managed to eventually get by because someone from the Adélie Linux team granted remote access to an unused Milk-V Pioneer, which proved enough for Chimera for now. My hope is still that eventually we’re going to see performant, capable RISC-V machines, because I would absolutely jump for joy if I could have a proper RISC-V workstation.
If I hadn’t done it before, I’d be tempted to suggest that the answer is cross compilation on a faster system. Truly, you’d be astonished just how many packages’ build systems just don’t work at all in cross compilation environment. Almost every package needs to be patched. some quite extensively.
I spent literal days trying to figure out how to cross compile gobject-introspection, so much time that by the time I’d finished I had completely forgotten what package’s dependency I was doing this for.. I can well understand why every distribution just decides that compiling on target is the only sensible course.
That said, it’d be a service to the community if some major distro were to decide that it should be possible to cross compile a complete release and committed to working with upstream maintainers to get everything in working order. It would help keeping modern distros working on other obscure or archaic architectures without necessarily having actual hardware on hand.
Thanks for that insight. Indeed my first thought was why would they not be cross compiling.
Jeeves,
Ideally cross compiling should be a perfectly sensible choice. In practice too many software builds make a bad practice of assumption that we’re targeting the currently installed environment, but usually that’s not too hard to fix. It’s usually quite trivial to set the necessary compiler flags. In my experience the real major problem is dependency hell. This can be a notorious dev problem even on a good day. With a project that has lots of dependencies and each of those dependencies needs to be cross compiled from source, I can see why that’s a miserable experience.
Cross compiling would be almost effortless if we managed to solve dependency hell problem. When running binaries, the distro’s repository provides the metadata to solve dependency issues for software install/execution. However when software developers are working with source from say github, it still comes down to using readme files and configure/make/cmake/etc outputting errors. Then we manually have to build dependencies one at a time. I create scripts so that I can execute patches and launch the entire build using a simple command, but it still takes a lot of work to get there.
Consistent standards would go a long way towards solving the problem, but outside of one’s own projects, good luck trying to standardize the rest of the world. Many years ago I tried with my distro and gave up. I had to make do with the software as it was because I don’t have the resources to raise the standard for everyone else’s software. 🙁
@Alfman
Native RISC-V is faster than cross-compiling at this point. Or at least cheaper than buying a monster machine to do it.
On another forum, one of the users posted this table of how long it takes to build the Linux kernel on hardware he has access to:
18m3.871s SpacemiT K3 8 X100 cores @2.4 GHz
19m12.787s i9-13900HX, 24C/32T @5.4 GHz, riscv64/ubuntu docker
39m23.187s SpacemiT K3 8 A100 cores @2.0 GHz
42m12.414s Milk-V Megrez 4 P550 cores @1.8 GHz
67m35.189s VisionFive 2, 4 U74 cores @1.5 GHz
70m57.001s LicheePi 3A, 8 X60 cores @1.6 GHz (same as BananaPI-F3)
88m04.185s LicheePi 4A, 4 C910 cores @1.85 GHz
The SpacemiT K3 has 16 cores, 8 X100 cores and 8 A100 cores. The A100 are meant to be for AI (in-order – 1024 bit vectors) but they are also just RISC-V. So you can build stuff on them too as you see above.
If you are building multiple packages, you can schedule work on both the X100 and A100 cores and get 50 percent better performance than just the X100 alone. Doing that, the K3 would be one of the fastest chips on Marcin’s list (if we think any of his numbers are for real chips).
LeFantome,
Aside: It’s nice to have a link whenever 3rd party material is referenced.
I think you mean “RISC-V is faster than compiling on x86 using a RISCV emulator”. In principal “cross-compiling” is actually very fast (ie native). So when you’re comparing these two lines…
I think they are comparing an x86 emulating RISCV versus a native RISCV compile.
If you were cross-compiling, the x86 should be far better.
Just for my own curiosity I found benchmarks for a SpacemiT K3 with 16 cores…
https://www.cnx-software.com/2026/01/23/spacemit-k3-16-core-risc-v-soc-system-information-and-early-benchmarks/
I ran the same benchmark on my own x86_64 machine and my computer ran circles around the SpacemiT K3 (short snippet):
My machine has about half the performance of a i9-13900, so if you’ll allow for some hand-waiving, I’d predict the i9-13900 might actually be able to cross compile the same code within 5m as opposed to 18m.
Cross compiling would bring huge speedups since they could use the fastest architecture to compile all the architectures. But the reason this is difficult is because they’re compiling thousands of projects and each of them would need their build environments to be patched to support cross compilation, which is just a pain.
My post is already getting too long but I think I’d be able to find a way to trick the build environments into automatically cross compiling every binary without the build environments being configured to do it by wrapping the compiler tools. It’d be worth a shot and if I were working for Fedora I’d give it a try.
@Alfman
> It’s nice to have a link whenever 3rd party material is referenced.
Agreed. But given that there are now several projects and technologies that we are not even allowed to use the names of here, I am afraid to link out to many sites. I did not want to “await moderation” or have my post deleted entirely.
It was just another user attestation anyway so no more authoritative than my hearsay. But I believe his numbers.
> I think you mean “RISC-V is faster than compiling on x86 using a RISCV emulator”.
> “cross-compiling” is actually very fast
Indeed and you are correct. Apologies and not sure how I made that mistake. I guess I was in the headspace of people building in QEMU since that is what distro build systems generally require. But you are absolutely right about the difference between emulation and cross-compiling. My head was somewhere else.
I am certainly making no claim that RISC-V is in i9 territory, or Apple Silicon, or Qualcomm X Elite (except for AI performance). I mean, the Tenstorrent Ascalon will release later this year and be twice as fast as a SpacemiT K3.
But RISC-V is not slow enough anymore to publish an article like Mancin’s. From the article you linked, the K3 is “slightly better than a Rockchip RK3588 SoC” and is faster multi-core than a Raspberry Pi 5. Multi-core performance matters for building packages.
Perhaps it would be possible to run the build system within an emulated linux VM with the exception of the compiler and linker. The stub could support some flag translation if the cross compiler version doesn’t support everything needed (but why wouldn’t it if everything is open source)? Compiler command could be a stub calling the networked cross compiler. Doesn’t seem to be rocket science, does it?
dsmogor,
Yeah, if you swap out the compiler to one that outputs a new architecture, the build scripts might not even need to know about it.
What I was thinking to optimize the process was to create a special compiler front end that outputs binaries for every target simultaneously into shadow directories – the build scripts don’t need to know you’re doing this and you’d get those binaries “for free”. This special front end could halt the build strait away if there is a compiler error for any of the architectures (or log and ignore errors for 2nd class architectures if preferred). You wouldn’t have to treat every target as a whole new build process. If it works, generating binaries for every target simultaneously could save a lot of effort and even require less disk IO in the process.
Theoretically doable, however there can be funny stuff happening when you’re building thousands packages from different sources. We’d just have to solve problems as they come up. For a project like Fedora that might have to repeat the process over and over I think a more or less transparent cross compiling solution would pay off in the long term.
Question from an uneducated Java Developer: Why not firing up QEMU instances on demand and build on the guest?
When wrapping SSE/AVX/NEON PNG encoder into Java, this worked wonders for me.
Andreas Reichel,
To point out the obvious, QEMU isn’t accellerated when emulating foreign architectures. In my own testing in the past, albeit not with RISCV, QEMU managed to get ~15-30% of native performance. The good news is that it worked though, so maybe it could work here.
Looking at the table… it looks like they’re getting 20% of x86_64 performance using real hardware, so emulation under QEMU would probably perform similarly. If they are able to build in parallel, then launching a bunch of slow QEMU VMs concurrently could be beneficial, but not if their build process is sequential.
https://marcin.juszkiewicz.com.pl/2026/03/10/risc-v-is-sloooow/
I’m also curious whether their build process is memory constrained? That 16GB ram might be bottlenecking the build. Is it swapping to disk? If so, that kills performance big time.
Note that the article itself discloses they’re not using the fastest RISCV hardware available, They can already get a 60% boost today. Clearly they should be supporting the faster board…
The author does use QEMU, but for some reason only provided build times for a different package than above so it’s not comparable…
The immediate fix seems obvious, use the faster Milk-V board, which takes a fraction of the time getting it much closer to the PPC build performance.
But I have a question of my own: is there a good technical reason to hold up all the architectures until RISCV is done building? What would be the negative in allowing architectures to release before RISCV? Surely given the size and nicheness of the audience it seems like a reasonable compromise to expect builds a bit later without insisting it holds up everyone else.
Thank you, doing only small stuff, I actually did not think of large packages like Firefox, LO or LLVM.
Given what it is, would it not be smart, to extent QEMU so it CAN accelerate RISCV? So to have one common denominator for all RISCV development?
It’s not “Acceleration” per se, it’s direct translation without passing through the TCG*. I’ll save myself some typing: https://arxiv.org/html/2501.03427v1 . The architectures need a way to map each other’s instructions 1:1, no exceptions.
Look at Box64 and FEX for direct translation of ARM amd64.
*Naturally when not emulating a different architecture, the TCG isn’t invoked.
Serafean,
Thank you for linking that, interesting paper! Obviously there’s room for improvement and if you could achieve a 1:1 mapping it would help. I wouldn’t necessarily say “no exceptions”, rarely used instructions don’t have to have a 1:1 mapping, the ones that are most important are instructions in critical pipelines.
Things that make this proposal complex in practice (off the top of my head):
1) different architectures may have different atomicity and memory barrier behaviors, Even if you have a 1:1 mapping of instructions, more instructions may be needed for syncing. Fortunately for x86 it’s one of the strictest, meaning that it should be easier for x86 to mimic other architectures than visa versa.
2) General purpose register pairings. x86 was always a register starved architecture. x86_64 doubled the number of registers, but it’s still less than most other architectures.
https://wiki.osdev.org/CPU_Registers_x86-64
https://www.cs.cornell.edu/courses/cs3410/2025sp/exams/prelim2-2025sp-ref.pdf
This means that other architectures can contain x86 state in CPU registers but visa versa is not possible (without relying on stack/cache lines. This presents a big disadvantage for x86.
3) Different mechanics for floating point/SSE/etc that have very similar purposes but work differently.
4) x86 has rather unique CISC memory addressing modes that would require composite instructions on some other architectures. A 1::1 mapping of memory access from another architecture to x86 seems strait forward, although it would probably be a little more performant to try and consolidate separate RISC instructions into one instruction on on x86 rather than keeping them 1:1 separate.
5) The use of flags/jumps/conditionals/etc may not be implemented in quite the same way between architectures. These instructions will be very common and may not have 1:1 mapping.
I always thought it would be a fun CS challenge to try and solve this problem myself, but there’s no doubt it would be very involved. I honestly think if we threw a NN at this problem, I suspect it would beat even the best human solutions.
Alfman,
> I wouldn’t necessarily say “no exceptions”, rarely used instructions don’t have to have a 1:1 mapping
I formulated too succinctly, I meant that all instructions (except probably those that are commonly checked for at runtime – think AVX and NEON), must be implementable using instructions of the host architecture.
Here is a presentation by one of the FEX devs talking about some of the issues you mention.
https://www.youtube.com/watch?v=3yDXyW1WERg
Serafean,
That dev got much further than I managed to a year or two ago when I was trying to get FEX running x86 steam games, haha. I gave up and ran long cords to an x86 computer. It’s good to see FEX is improving. I hope to try it again one day.
Is there anymore data? I mean, has anybody looked at exactly *why* this is 5X slower? Is this *just* CPU bandwidth or is there (compounded) other reasons like disk I/O performance, scheduling issues, memory bandwidth etc. I couldn’t see anything except a comparison of core counts which is only 1 factor.
ppp,
I have the same question. A screenshot of “top” would reveal a lot!
I don’t have access to any of this hardware, but if I did I would run it through a gamut of sysbench tests for memory/disk/cpu performance relative to x86 and ARM just to get a rough idea of what the bottlenecks are.
Also, since a significantly faster RISCV SBC is available I think fedora should be using it.
https://milkv.io/
I know the author says the vendor behind the current model is better supported. So how long do you stick with a vendor you prefer with an inferior product before deciding the upgrade is necessary to get the better performance? This reminds me of kurkosdr criticizing users wanting to run linux on top of class hardware with bad support (albeit with apple and ARM instead of RISCV). It’s a dilemma and I’m curious what kurkosdr would say here.
https://www.osnews.com/story/144532/the-new-macbook-neo-is-a-great-deal-in-the-us-not-so-much-in-europe/#comment-10456546
Well, T2 SDE Linux has solved it 20y ago by cross compiled everything. We even recently released a full cross compiled Qt6 KDE Plasma Desktop. The whole release ISO built )over 600 pkgs) on 2 year-old 7950x in under 4h. https://t2linux.com
RISC-V seems to eat up a lot of ARM’s previous lower end embedded market. So it’s not quite accurate to say it’s no a success. It just haven’t been so in the big C computer market.
The fact that it’s even possible to run Linux *at all* with such a young ISA is fairly impressive in it’s own right. RISC-V in the lower embedded space solves a problem that ARM simply didn’t, by allowing companies to develop highly customised cores for their purposes (AFAIK all hard drive producers have bespoke RISC-V cores in their disks these days for example). However, I’m not sure what problem RISC-V solves that there is a strong business case for.
Don’t get me wrong, I think RISC-V is very cool and I’d love to see something like it also be successful in full-on computers. 🙂
This was discussed on another forum.
The conclusion there was that, if the 143 minutes applied to the BananaPi-F3, the SpacemiT K3 would compile binutils in 36 minutes using its X100 cores (half of its cores). This is the same time as he gives for Aarch64.
The BananaPi-F3 is just a guess based on what he says later and the fact that he says a P550 would be an improvement.
He does not identify any of the hardware which makes this hard to take too seriously.
I kind of suspect that none of those times are “real” hardware. Rather, I think they have a build farm of multiple machines and he is attempting some kind of average to suggest build times for each architecture. For example, does it make sense that i686 is building as fast as x86-64?
RISC-V hardware two years ago was crazy slow. It is all pretty slow even over the past 12 months. The stuff coming out now is still a bit slow single core but decent multi-core and so not as bad as he says for building distros. The stuff coming out later this year is pretty fast (not M5 or Panther Lake fast of course, though the SpacemiT K3 is faster at AI than an M4).
> RISC-V really seems to have hit some sort of ceiling over the past few years
The biggest reason for that perception is largely because the Milk-V OASIS never shipped. It was to feature a Sophgo SG2380 processor which had 16 SiFive P670 cores. TSMC refused to make them when Sophgo was accused of violating US sanctions. It would have launched over two years ago and been far more powerful than any RISC-V chip in the market today. That was a huge blow to RISC-V.
Another reason is that RISC-V companies keep getting bought. Ventana got bought by Qualcomm before they could release their new chip. Rivos got bought by Meta. Those companies will still release chips. We may just not be able to buy them.
SiFive has designed even more powerful cores, like the P870 but nobody has licensed them yet. Like many RISC-V companies, they design chips but do not make them. Somebody has to license the design and tape it out. But other RISC-V companies are going to make their own silicon. The Tenstorrent Atlantis (their own silicon implementation of their Ascalon architecture) has many people excited as it claims Ryzen 5 peformance in Q2/Q3 of this year.
But, despite the lumpiness, it is not true that RISC-V is not getting faster. In my other comment, I included Linux kernel build times on various hardware. The new stuff, like the K3, is certainly faster.
LeFantome,
Yeah it’s easy to dis the new kid on the block but they’re being compared to incumbents who have all the money, aren’t facing sanctions, have first dibs on new fab technology, have scales of economy, etc.
I checked and SpacemiT_K3 is on a 12nm node.
https://grokipedia.com/page/SpacemiT_K3
I’d love to see RISCV succeed but it’s an uneven playing field so I think expectations need to be set accordingly.
I do look forward to seeing improvements. Honestly the killer feature for me would be rallying RISCV manufacturers around a universal boot standard, if they don’t blow it. Piss-poor standards is one of the most frustrating aspects of deploying FOSS operating systems on ARM SBCs, mobiles, etc.
@LeFantome
The main issue with RISC-V regarding performance is the same as everybody else: high performance out-of-order micro architectures are expensive to design, validate, and manufacture.
And the ISA (or its licensing) makes little difference there.
Software sells chips, not the other way around. And right now there is no software case for high end RISC-V parts, ergo why they are not getting any traction in the market. This is, no organization is going to sink half a billion $$$ to create a high performance RISC-V based SoC, for a non existing user base/software library. Thus the usual chicken and egg limbo.
RISC-V is having a lot of success in the tiers where it makes sense: embedded/IoT stuff, which does not require high design complexity cores, and startup/academic research that are very sensitive to licensing costs and other related issues.
RISC-V was never meant to run work stations (or servers). It is based on a very old architecture that has been extended, but shows its (design) age. It is fine for embedded stuff like hard disk controllers, but to drag it into the work station space it needs quite some improvements. Not to mention the lack of standardization (or rather the extensive configurability) that also plagues work station ARM.
jalnl
Do you have specifics? I mean x86 shows it’s age too, with notable engineering shortcomings, but look at how far we’ve kept dragging it along and extending it because the money and interest was there even though there were better building blocks. I’d like to hear the specific designs that you don’t think are aging well.
I am curious if you have examples? For servers you want performance but often times efficiency (with parallelism) is more important than core performance. Given the nature of the work that servers typically need to handle, it can make sense to sacrifice CPU complexity (needed to eek every IPC out of a core) and instead focus simpler cores that are more efficient and just have more of them. Look at big tech firms like amazon and google building their own ARM hardware for platforms like AWS. They weren’t beating x86 on performance, but they were trouncing x86 on efficiency.
I want to study more about RISCV to get a better understanding of it’s architectural strengths and weaknesses better (and not just comparing them to CPUs that obviously do better because those CPUs were blessed by better fabs).
I really like the idea of having an open architecture and for it to succeed, but I think the FOSS community are desperate for something that works like x86 in terms of bring-your-own-OS to arbitrary commodity hardware…not having to worry about every device requiring a custom OS image. ARM has been an incompatibility cluster-f***. I don’t mind some teething issues with RISCV while it’s sorted out, but long term it will be such a lost opportunity if RISCV ends up being another ARM. The FOSS community deserves an open architecture that works without those headaches.
RISC-V is a general scalar ISA, It is not Use Case specific.
jalnl,
This is demonstrably wrong.
It is a clean redesign (at least back then) designed in UC Berkley in 2010s:
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer#Berkeley_RISC_and_Stanford_MIPS
It is not beholden to backwards compatibility with any architecture (ARM, MIPS, Sparc, or of course x86)
Starting a political discussion isn’t investing in RISCV handing over the west lunch to the Chinese for free? Sure, ARM is patented and not open source but at least those patents lay in the hands of a western company.