There is a specific kind of disappointment that comes from believing in an architecture and then actually trying to build software on it. Marcin Juszkiewicz wrote about it plainly in RISC-V is sloooow, a piece that lands with the credibility of someone who has done the same benchmarking exercise across ARM, AArch64, and x86 systems for years.
The short version: RISC-V hardware, as it exists today in developer-accessible boards and workstations, is dramatically slower than equivalent AArch64 or x86_64 silicon. Not slightly. Dramatically.
Why the Gap Exists
RISC-V as a specification is elegant. The base ISA is clean, the extension system is modular, and the lack of legacy baggage is genuinely freeing. None of that translates directly into performance.
Performance comes from microarchitecture: out-of-order execution, branch prediction, cache hierarchies, speculative execution, and the decades of engineering investment that go into making those things work well together. x86 and ARM implementations have had those investments for a long time. The best RISC-V silicon available to most developers today has not.
The boards in the hands of people actually packaging software, things like the Milk-V Pioneer with SG2042 or earlier SiFive boards, are running cores that are slow by modern standards. The SG2042 is a 64-core chip, which sounds impressive until you realize those cores are in-order or weakly out-of-order, clocked conservatively, with memory subsystems that have not been tuned the way a Graviton or an Apple Silicon chip has been tuned.
Clock-for-clock, single-threaded RISC-V performance on available hardware is well behind AArch64. Throwing 64 slow cores at a compilation job helps, but many real workloads do not scale that way.
The Packaging Problem
Marcin’s vantage point is meaningful here. He works on distribution-level packaging, which means compiling enormous amounts of software repeatedly. Build times are not an abstract metric for him; they are the cost of doing his job. When he says something is slow, he means it adds real hours to real workflows.
This matters beyond his individual situation. Every developer who tries to bootstrap a RISC-V port of a Linux distribution, every person trying to cross-compile and then verify, every CI pipeline that runs on RISC-V hardware, feels this. The feedback loop that makes software ecosystems healthy depends on iteration speed, and slow hardware taxes every iteration.
Is This Permanent
No, but the timeline is uncertain. There are promising microarchitectural designs in progress. SiFive’s P870, Ventana’s Veyron V2, and Rivos have all been working on genuinely high-performance RISC-V cores. The RISC-V International ecosystem has the commercial backing now to fund serious silicon work.
The problem is that “promising” and “available to developers who need to build packages today” are very different things. The hardware that will make Marcin’s build times competitive with his AArch64 or x86 machines probably exists in some lab right now, but it is not on his desk.
What This Means in Practice
If you are evaluating RISC-V for production workloads in 2026, the honest answer is that the architecture is not ready to compete on raw performance with mature alternatives. That is not a reason to abandon it; the long-term trajectory is sound and the architectural cleanliness is real. But it is a reason to be precise about what you are choosing it for.
For distribution maintainers, systems developers, and anyone doing build-heavy work, the current generation of hardware is a genuine obstacle. Marcin’s post is a useful data point from someone who does not have an ideological axe to grind, just build logs and elapsed time numbers. Those are worth taking seriously.