RISC-V Is Painfully Slow for Servers Right Now — But Here Is Why You Should Still Pay Attention

RISC-V Is Painfully Slow for Servers Right Now — But Here Is Why You Should Still Pay Attention

A Fedora Linux developer named Marcin Juszkiewicz published a blog post yesterday with the kind of title that makes server hardware enthusiasts either nod knowingly or clutch their RISC-V development boards in defense: “RISC-V Is Sloooow.”

Three extra O’s. He meant it.

The post is actually a thoughtful assessment from someone who has spent three months porting Fedora Linux to the RISC-V architecture, and his benchmarks tell a story that anyone considering RISC-V for server infrastructure needs to hear. I am going to walk through what he found, what it means for the cloud and hosting world, and whether RISC-V servers are anywhere close to being something you should care about.

Spoiler: not yet. But the “yet” matters.

The Benchmarks That Started the Conversation

Juszkiewicz compared build times for the binutils package (a fundamental piece of the Linux toolchain) across multiple architectures. The results are, well, educational:

ArchitectureCoresRAMBuild Time
x86_64829 GB29 min
i686829 GB25 min
aarch64 (ARM)1246 GB36 min
ppc64le1037 GB46 min
s390x345 GB37 min
riscv64816 GB143 min

Let that sink in. The RISC-V build took 143 minutes compared to 29 minutes on x86_64. That is nearly 5x slower. And this was on the StarFive VisionFive 2, which is one of the more available RISC-V boards out there.

Server rack in datacenter with blinking LED lights and cable management

Even on the newer Milk-V Megrez board, it still took 58 minutes — double what x86 achieved. And this is with LTO (Link-Time Optimization) disabled on the RISC-V build, which means the comparison is not even apples-to-apples. With LTO enabled, the RISC-V numbers would be even worse.

My colleague James, who manages build infrastructure at a mid-size hosting company, looked at these numbers and said: “That is not a performance gap. That is a generational gap. Those RISC-V cores are competing with ARM Cortex-A55, which is the efficiency core in modern ARM chips. It is like comparing a Corolla to a Tesla and being surprised the Corolla is slower.”

Why RISC-V Hardware Is Where It Is

Before we write off RISC-V entirely, it helps to understand why the hardware is so slow right now. The answer is not “RISC-V is a bad architecture.” The answer is “RISC-V is a young architecture that has not had billions of dollars of optimization poured into its implementations yet.”

RISC-V is an open-source instruction set architecture (ISA). Anyone can design a RISC-V processor without paying licensing fees. This is fundamentally different from x86 (controlled by Intel and AMD) and ARM (licensed by Arm Holdings). The openness is RISC-V’s biggest strength and, right now, its biggest weakness.

The strength: it enables a diverse ecosystem of chip designers, from startups to universities to major corporations, to build processors without the licensing overhead that ARM charges. This is particularly attractive for specialized applications, embedded systems, and countries or organizations that want hardware sovereignty.

The weakness: nobody has yet invested the kind of money that Intel, AMD, and Qualcomm have spent over decades optimizing their processor designs. The best RISC-V cores available today have performance comparable to ARM Cortex-A55 — the little efficiency cores that sit alongside the powerful performance cores in modern ARM chips. They are fine for IoT devices. They are not fine for servers.

What This Means for Hosting and Cloud Infrastructure

Let me be direct: RISC-V is not ready for production server workloads. Not even close. And anyone selling you RISC-V cloud instances today is selling you a developer experience, not a production environment.

But I want to add some nuance, because I think dismissing RISC-V entirely would be a mistake.

The ARM Parallel

Remember when ARM servers were a joke? I do. Around 2016-2018, running a production workload on ARM was considered adventurous at best and irresponsible at worst. The software was not ready, the hardware was not competitive, and the ecosystem barely existed.

Fast forward to 2026: AWS Graviton processors (ARM-based) now power a significant chunk of AWS workloads and deliver better price-performance than their Intel counterparts for many use cases. Ampere Altra chips are in data centers worldwide. Apple’s M-series processors (also ARM) have transformed the laptop market.

ARM went from “not ready for servers” to “better than Intel for many workloads” in about 5-7 years. RISC-V is following a similar trajectory, just earlier in the curve.

The Timeline I Would Bet On

  • 2026-2027: RISC-V remains a development and testing platform. Useful for CI/CD to ensure your software compiles on the architecture, but not for serving traffic.
  • 2028-2029: The first competitive RISC-V server chips arrive. Companies like SiFive, Tenstorrent, and possibly some Chinese chip makers ship chips that compete with mid-range ARM Cortex-A78 class cores.
  • 2030+: RISC-V becomes a viable third option alongside x86 and ARM for certain workloads, particularly in edge computing, specialized AI inference, and markets where hardware sovereignty matters.

Should You Care Right Now?

If you are a hosting provider, cloud infrastructure company, or DevOps engineer, here is my practical advice:

Do not plan to deploy RISC-V in production. The hardware is too slow, the software ecosystem is immature, and you will spend more time fighting compatibility issues than serving customers.

Do make sure your software builds on RISC-V. If you maintain open-source software or packages used in Linux distributions, testing RISC-V compatibility now avoids a painful scramble later. Fedora’s RISC-V porting effort (which Juszkiewicz is part of) is specifically working to get this ecosystem ready.

Do watch the chip announcements. The UltraRISC UR-DP1000 and SpacemiT K3 are both upcoming chips that should improve the situation, though neither will close the gap with ARM or x86. The chip that matters will likely come from SiFive’s P870 or P880 cores, which are aiming squarely at the server market.

Do not fall for RISC-V hype from vendors. I have seen hosting companies add “RISC-V instances” to their product pages as a marketing differentiator. That is fine for developers who want to test, but it is not a production offering.

The Elephant in the Server Room

There is a geopolitical angle here that often gets ignored in technical discussions. RISC-V is open-source, which means it is not subject to export controls or licensing restrictions. For countries like China, India, and Russia, RISC-V represents a path to hardware independence that does not depend on Western chip designers.

China in particular is investing heavily in RISC-V. Alibaba’s T-Head subsidiary has already produced competitive RISC-V cores, and several Chinese semiconductor companies are developing server-class RISC-V chips.

Derek, who tracks semiconductor supply chains for a living (it is apparently a thing you can get paid for, and I am still slightly jealous), put it this way: “RISC-V might not beat ARM or x86 on pure performance for a decade. But it will win markets where the alternative is ‘no chip at all’ because of export controls. And those markets are not small.”

The Bottom Line

RISC-V is slow. Marcin Juszkiewicz is right, and the benchmarks do not lie. Today’s RISC-V hardware competes with the weakest cores in the ARM lineup, and it takes 5x longer to compile the same code that x86 handles comfortably.

But “slow today” is not “slow forever.” The ARM story proved that. What RISC-V needs is time, investment, and a few breakout chip designs that prove the architecture can compete at the high end.

For now, stick with what works: x86 or ARM for production, RISC-V for experimentation and compatibility testing. Keep an eye on SiFive, Tenstorrent, and Alibaba T-Head for the chips that might change this calculus.

And if someone tells you their new RISC-V dev board “feels fast”? Ask them to compile binutils on it and get back to you in about two and a half hours.

(Two and a half hours. I am going to think about that number every time I complain about my x86 build taking four minutes. Perspective is a wonderful thing.)

📚 Related reading:

Found this helpful?

Subscribe to our newsletter for more in-depth reviews and comparisons delivered to your inbox.