RISC-V Is Sloooow

Original Article ↗ Hacker News Discussion ↗

Claims that “RISC‑V is slow” are prompting scrutiny of whether the problem lies in the open ISA itself or in today’s immature, low-end silicon and toolchains. Contributors note that current RISC‑V boards used for tasks like building full Linux distributions are years behind modern ARM and x86 in single‑core performance, memory bandwidth, and ecosystem support, making native builds and testing painfully slow. Others argue that the ISA is fundamentally sound but hampered by uneven extensions, conservative compiler defaults, and a lack of high‑performance, widely available chips—though upcoming RVA23‑class designs and Chinese vendors could narrow the gap later in the decade.

Current RISC‑V Performance

  • Consensus: today’s widely available RISC‑V hardware is notably slower than contemporary ARM and x86 for general workloads like compiling large codebases.
  • Typical SBCs (e.g., current Banana Pi, VisionFive‑class boards) are roughly in the Cortex‑A55 to A76 range, i.e., several years behind mainstream ARM and far behind modern x86.
  • Some newer or upcoming SoCs (SpacemiT K3, P550-based boards, Tenstorrent Ascalon/Atlantis) are reported or promised to reach “laptop-class” (M1 / mid‑Ryzen era) performance, but are not yet widely available.
  • There is surprise at strong s390x performance in the benchmarks, and acknowledgment that I/O and memory systems matter as much as pure core speed.

ISA vs Silicon Implementations

  • Many argue the ISA is not inherently slow; the bottleneck is immature microarchitectures, weak memory subsystems, small core counts, low clocks, and early‑stage toolchains.
  • Others counter that assuming RISC‑V “will get there” is wishful until high‑end, shipping silicon proves it, noting historical hype cycles around MIPS and SPARC.
  • Some highlight that high performance also requires huge investment in analog/PHY, caches, DDR/PCIe, not just an RTL core.

ISA Design and Extensions

  • Criticisms:
    • Missing or awkward basics (no overflow flag, limited indexed addressing, messy misaligned load/store semantics, 4 KiB base pages, bit‑manipulation not in the base ISA).
    • Integer overflow detection and multiword arithmetic require multiple instructions; some see this as a serious design flaw, others say the overhead is modest and can be micro‑fused.
  • Defenders note RISC‑V was intentionally minimal and modular, with many problems addressed by standardized extensions (bitmanip, atomics, misaligned access, vectors) and profiles like RVA23 that bundle a “desktop/server‑class” feature set.
  • Debate over whether modularity is a strength (flexible, small embedded cores) or a liability (binary distribution becomes profile‑specific; you can’t count on extensions).

Tooling, Builds, and Cross‑Compilation

  • Major distros prefer native builds with full test suites; cross‑compiling 25k+ packages is described as fragile and labor‑intensive due to build‑system assumptions, host/target confusion, and tests that run built binaries.
  • Some argue cross‑compilation is tractable (Yocto, specialized Docker images, language‑level cross‑compilers), but others stress the ongoing maintenance cost.
  • Result: current slow RISC‑V builders significantly delay distro rebuilds, though newer boards already show large improvements.

Market, Ecosystem, and Trajectory

  • Viewpoints diverge on whether RISC‑V “needs” to chase desktop/server performance; it’s already succeeding in tiny embedded and “janitorial” cores.
  • High‑end designs may come from AI/HPC vendors and from regions locked out of ARM/x86 licensing. Sanctions and cancellations of some promising SoCs are seen as having slowed progress.
  • Some expect ARM‑64 / RISC‑V performance parity sometime in the 2030s; skeptics see this as optimistic and emphasize that performance leadership requires sustained, very large investments.