Linus Torvalds says RISC-V will make the same mistakes as Arm and x86

Original Article ↗ Hacker News Discussion ↗

Concerns over RISC-V’s future center on whether its open, highly extensible instruction set will repeat the complexity, fragmentation, and security pitfalls seen in x86 and Arm, particularly around issues like Spectre-style vulnerabilities and inconsistent CPU feature support. Supporters argue that the open standard, diverse implementations, and formalized extension mechanism are strengths that enable innovation, competition, and resilience against vendor lock-in, with profiles and tooling intended to keep the software ecosystem coherent. Others worry that the sheer number of possible extension combinations, uneven performance of certain instructions, and diverging hardware trade‑offs (e.g., vector units, microcontroller vs server features) could make predictable performance and broad software compatibility harder to achieve.

Headline and Torvalds’ actual stance

  • Several comments say the article headline is misleading: Torvalds frames it as “I fear / suspect” rather than predicting with certainty.
  • The concern is mostly about repeating systemic mistakes (ecosystem, security, abstraction boundaries), not that RISC‑V implementations will be flawless or doomed.

Open ISA vs. vendor lock‑in

  • Strong support for RISC‑V’s open standard: many vendors can design cores; if one fails or exits, others can replace it.
  • This is contrasted with historical dead‑end architectures (Itanium, Alpha, 68k, etc.) and corporate‑controlled platforms that died through mismanagement.
  • Some see RISC‑V as to hardware what Linux and x86/PCI/BIOS did for open system design.

Fragmentation, extensions, and profiles

  • Big thread on ISA fragmentation: x86 has many SIMD/feature variants; RISC‑V goes further with a highly modular extension system.
  • Critics worry about “over 1 quintillion” legal combinations and vendor‑specific extensions.
  • Defenders argue:
    • Most general‑purpose software will target standardized “RVA” profiles.
    • Embedded vendors already manage bespoke toolchains (similar to ARM today).
    • Custom extensions can later be standardized if they prove useful.

Performance and “ISA vs implementation”

  • Debate over whether ISA materially affects performance:
    • One side: ISA details (fixed vs variable length, decode cost, vector model) matter; Apple M‑series and ARM64 are cited as evidence.
    • Other side: RISC‑V vs ARM vs x86 differences show implementation quality dominates, not the ISA itself.
  • Detailed sub‑thread on RISC‑V compressed (C) instructions and decode complexity; consensus: more complex than AArch64 but vastly simpler than x86, and practically manageable.

Vector ISA (RVV) vs fixed‑width SIMD

  • Long, technical back‑and‑forth on RISC‑V’s scalable vector extension (RVV) vs fixed‑width SIMD (NEON, AVX).
  • Critics: RVV’s flexibility complicates performance guarantees, especially for shuffles/gather (e.g., vrgather) and fixed‑width style workloads.
  • Supporters: RVV can emulate fixed‑width patterns and scale to long vectors; real hardware (e.g., low‑end RVV chips) already performs comparably to NEON on some codecs.
  • Some acknowledge specific design warts (e.g., vrgather using same LMUL for table and indices) and suggest future refinements.

Complexity creep and “repeating history”

  • Meta‑theme: ISAs and software both start simple, then accumulate special‑case instructions/features for performance or convenience until they become “overcomplicated,” prompting new “clean” designs.
  • Several see RISC‑V as better‑positioned than x86 (cleaner base, learned lessons), but agree it won’t avoid complexity entirely.