RISC-V ist viel zu langsam

 (marcin.juszkiewicz.com.pl)
3 Punkte von GN⁺ 2026-03-24 | 1 Kommentare | Auf WhatsApp teilen
  • Die RISC-V-Portierung von Fedora Linux läuft seit etwa drei Monaten, und die meisten Pakete wurden bereits für Fedora 43 gebaut
  • Aktuelle RISC-V-Hardware zeigt sehr langsame Build-Geschwindigkeiten; beim Bau desselben Pakets wird im Vergleich zu x86_64 teils mehr als die fünffache Zeit benötigt
  • Um als offizielle Fedora-Architektur aufgenommen zu werden, ist servertaugliche Hardware erforderlich, die binutils in weniger als einer Stunde bauen kann
  • Die Build-Verzögerungen sorgen für Unzufriedenheit bei Paket-Maintainern, und es wird auch die Möglichkeit erwähnt, dass RISC-V ausgeschlossen werden könnte
  • Künftig sollen die Fedora-44-Builds und schnellere Builder das Geschwindigkeitsproblem verbessern; außerdem sind eine Vereinheitlichung des Kernels und die Beibehaltung der deaktivierten LTO geplant

Fortschritt bei der Fedora-RISC-V-Portierung

  • Die RISC-V-Portierung von Fedora Linux läuft seit etwa drei Monaten, und in dieser Zeit hat es mehrere Änderungen gegeben
  • Die meisten Einträge im Fedora-RISC-V-Tracker wurden abgearbeitet; derzeit verbleiben nur noch 17 Einträge mit dem Status NEW
  • Fedora-Paketquellen werden übernommen und mit dem Befehl fedpkg mockbuild -r fedora-43-riscv64 gebaut
  • Bisher wurden 86 Pull Requests für Pakete eingereicht, die größtenteils bereits gemergt wurden; die Builds für Fedora 43 sind abgeschlossen
  • Zusätzliche Builds können anhand des Tags „f43-updates“ weiter durchgeführt werden

  • Problem bei der RISC-V-Build-Geschwindigkeit

    • RISC-V-Hardware zeigt derzeit sehr langsame Build-Geschwindigkeiten
    • Die Build-Zeit für binutils 2.45.1-4.fc43 wurde mit 143 Minuten auf riscv64, 36 Minuten auf aarch64 und 29 Minuten auf x86_64 gemessen
    • Das verwendete StarFive VisionFive 2 Board bietet eine gute Treiberunterstützung, ist aber langsam
    • Beim Bau desselben Pakets auf dem Milk-V Megrez Board wurden 58 Minuten benötigt
    • Aktuell erfolgen RISC-V-Builds mit deaktivierter LTO (Link Time Optimization), um Speicherverbrauch und Build-Zeit zu senken
    • Die Builder verfügen über 4 bis 8 Kerne und 8 bis 32 GB RAM; ihre Leistung wird auf das Niveau eines Arm Cortex-A55 geschätzt
    • Als Hoffnungsträger für Verbesserungen gelten künftig der UltraRISC UR-DP1000 SoC (bis zu 64 GB RAM) und SpacemiT-K3-basierte Systeme (bis zu 32 GB RAM)

  • Voraussetzungen für die Aufnahme als offizielle Fedora-Architektur

    • Um als offizielle Fedora-Architektur aufgenommen zu werden, ist Hardware nötig, die das Paket binutils in weniger als einer Stunde bauen kann
    • Auch bei systemweit aktivierter LTO muss eine Geschwindigkeit auf dem Niveau anderer Architekturen erreicht werden
    • Build-Ergebnisse werden erst dann ins Repository übernommen, wenn alle Architekturen fertig sind; langsame Builder führen daher zu Unzufriedenheit bei Paket-Maintainern
    • Schon früher gab es Beschwerden über die Geschwindigkeit von AArch64-Buildern, und einige Entwickler erwähnten die Möglichkeit, RISC-V auszuschließen
    • Zukünftige Builder müssen serverartige Systeme sein, die sich ins Rack einbauen und remote verwalten lassen; SBC-basierte Umgebungen mit manuellem Reboot sind ungeeignet
    • Werden diese Bedingungen nicht erfüllt, ist eine Aufnahme von RISC-V als offizielle 64-Bit-Architektur in Fedora nicht möglich

  • Lokale Tests mit QEMU

    • Wegen der langen Build-Zeiten sind lokale Tests mit QEMU-Emulation nützlich
    • Auf einem AArch64-Desktop mit 80 Kernen lässt sich das Paket llvm15 per QEMU-Userspace-riscv64-Emulation in rund 4 Stunden bauen
    • Dasselbe Paket benötigt auf einem Banana Pi BPI-F3 Builder 10,5 Stunden
    • Da LLVM-Pakete sowohl Kerne als auch Speicher stark ausnutzen, werden Leistungssteigerungen auf Ampere-One-basierten Systemen mit 192/384 Kernen erwartet
    • QEMU wird nur für lokale Builds und Tests genutzt; Fedora führt ausschließlich native Builds durch

  • Ausblick

    • Der Start der Fedora-Linux-44-Builds ist geplant
    • Ziel ist, auf allen Buildern dasselbe Kernel-Image zu verwenden; derzeit sind noch verschiedene Kernel-Versionen im Einsatz
    • LTO soll weiterhin deaktiviert bleiben
    • Zur Lösung der Geschwindigkeitsprobleme ist die Einführung neuer und schnellerer Builder geplant; einige schwere Pakete sollen diesen Buildern zugewiesen werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-24
Hacker-News-Kommentare

  • Ich denke, man sollte weniger die ISA selbst verantwortlich machen als vielmehr die Silizium-Implementierung und die Software, der architekturspezifische Optimierungen fehlen.
    Auch RISC-V wird sich letztlich weiterentwickeln.
    ARM war anfangs ebenfalls auf Geschwindigkeit ausgerichtet, wechselte später aber in Richtung Energieeffizienz, war damit im Embedded-Markt erfolgreich und scheint inzwischen wieder stärker auf Geschwindigkeit zu setzen.

    • In manchen Fällen ist jedoch tatsächlich die RISC-V-ISA-Spezifikation selbst das Problem.
      Beispiele dafür sind etwa LLVM Issue #150263 und #141488.
      Außerdem ist die Seitengröße fest auf 4 KiB gelegt, was die Leistung im Vergleich zu ARM einschränken kann.
    • Der Aussage „RISC-V wird irgendwann schon aufholen“ kann ich nur schwer zustimmen.
      ARM war schnell, wurde dann langsamer und wurde später wieder schnell, aber RISC-V hat bislang noch nie im High-Performance-Bereich echte Konkurrenzfähigkeit gezeigt.
      Implementierungen kleiner Teams sind beeindruckend, doch für Mobile-, Desktop- und Server-Klassen reicht es weiterhin nicht.
    • Die Aussage „Es ist nicht die ISA, sondern die Implementierung“ stimmt zwar, ist aber auch ziemlich offensichtlich.
      In der Praxis sind Dinge wie Cache-Strukturen sowie analoges VLSI-Design für DDR- und PCI-Interfaces entscheidend, und es gibt kaum Teams, die das wirklich beherrschen.
      Außerdem wollen alle Firmen „High-Performance-RISC-V-Anbieter“ werden, aber niemand will den Embedded-Markt übernehmen.
      In den USA werden Chips eher nicht selbst produziert, sondern es wird nur IP verkauft, sodass man für reale Hardware faktisch auf chinesische Anbieter angewiesen ist.
    • Betrachtet man das Muster der CPU-Leistungsentwicklung, wiederholt sich oft ein Zyklus: Zuerst wird die Energieeffizienz optimiert, danach steigt die Geschwindigkeit.
      Ein typisches Beispiel ist, wie die Netburst-Architektur des Pentium 4 an ihre Grenzen stieß und die aus stromsparenden Kernen abgeleitete Core-Architektur zum Hauptpfeiler von Intel wurde.
      Auch die Geschichte von ARM zeigt einen ähnlichen Verlauf.
    • In einem Video von LowSpecGamer wird erzählt, dass frühe ARM-Chips sogar nur mit Schutzdioden funktioniert hätten.
      Laut Steve Furber war die Effizienz so hoch, dass Code lief, obwohl man vergessen hatte, die Stromversorgung anzuschließen.

  • Es wird eine Korrektur zu einem Blogbeitrag eines Kollegen geteilt.
    Im Fedora-RISC-V-Build-System wurde ein binutils-Build auf einem Milk-V „Megrez“ in 67 Minuten abgeschlossen, was eine deutliche Verbesserung gegenüber dem früheren Wert von 143 Minuten ist.
    Das derzeit schnellste Entwicklerboard ist nicht das Banana Pi, sondern das SiFive „HiFive P550“ und das UltraRISC „DP1000“.
    Der FOSDEM-Vortrag „Fedora on RISC-V: state of the arch“ behandelt ebenfalls entsprechende Benchmarks.
    Marcins Test wurde auf einem StarFive „VisionFive 2“ durchgeführt; dieses Board ist zwar stabil, aber eher langsam.

    • Das VisionFive 2 ist zuverlässig, aber ein mehr als drei Jahre altes Board, das bei aktuellen Builds an Speichergrenzen stößt.
      Um beim gcc-Build vier Binärdateien gleichzeitig zu linken, werden mindestens 16 GB benötigt, und mit aktiviertem Swap läuft es stabiler.
      Auf dem VisionFive 2 muss man mit -j1 oder -j2 bauen, wodurch sich die Zeit um das Zwei- bis Vierfache verlängert.
      Effizienter wäre ein besserer Linker (als Ersatz für ld) oder wie im LLVM-Build-System eine separate Vorgabe der Zahl paralleler Link-Vorgänge.

  • ARM hat 40 Jahre gebraucht, um an seinen heutigen Stand zu kommen, und RISC-V ist erst 15 Jahre alt.
    Dieses Jahr will Tenstorrent eine serverbasierte Plattform auf RVA23-Basis veröffentlichen, also lohnt es sich, das weiter zu beobachten.
    Entscheidend ist letztlich, dass die Hardware-Anbieter leistungsfähiges Silizium auf den Markt bringen.

    • RISC-V wurde stark von MIPS beeinflusst, und auch MIPS galt Anfang der 1990er als sehr vielversprechend, wurde am Markt am Ende aber verdrängt.
    • AArch64 ist zwar ebenfalls erst 15 Jahre alt, aber gegenüber 32-Bit-ARM fast eine vollständig andere Architektur.

  • felix baut mit einem Milk-V Pioneer das Arch-Linux-RISC-V-Repository.
    Ich denke, dass auch die durch die SOPHGO-Sanktionen verlangsamte Entwicklung eine Ursache ist.
    Das auf dem SG2380 von SOPHGO basierende Milk-V Oasis wurde zwar gestrichen, war aber ein sehr vielversprechendes SoC.
    Die Chips dieser Firma unterstützten eine Dual-Architektur, zwischen ARM und RISC-V konnte also umgeschaltet werden.
    Siehe Arch-RISC-V-Repository und den zugehörigen Artikel.

    • Ich würde gern konkreter verstehen, welche Sanktionen tatsächlich welche Auswirkungen hatten.

  • Ich frage mich, warum RISC-V-Software unbedingt auf einem RISC-V-System gebaut werden muss.
    Compiler betten Informationen über die Zielarchitektur in den Code ein, also müsste es theoretisch doch auch auf einem anderen System möglich sein.

    • Um eine komplette Distribution cross zu kompilieren, muss diese Distribution das auch unterstützen.
      Fedora unterstützt derzeit nur Native Builds, und Cross-Compiler gibt es nur als Bare-Metal-Versionen für Firmware.
      Außerdem ist automatisiertes Testen schwierig, daher sind Native Builds auf echter Hardware für Tests realistischer.
      AArch64 war anfangs ebenfalls langsam, hat sich aber so weit entwickelt, dass ein Qt4-Build heute in 18 Minuten fertig ist.
    • Es gibt viele Abhängigkeitsprobleme, weil Build-Skripte Bibliotheken oder Einstellungen des Host-OS referenzieren.
      Das lässt sich je nach Sprache lösen, aber besonders im C/C++-Ökosystem ist es komplex.
      Deshalb wird meist in einer VM oder auf echter Zielhardware gebaut.
    • Frühere Compiler wählten das Backend zur Compile-Zeit aus, deshalb war Unterstützung mehrerer Architekturen schwierig.
      Seit LLVM ist das möglich, aber für Tests braucht man weiterhin einen Emulator.
    • Cross-Builds sind an sich möglich, aber das Testen nach dem Build benötigt noch mehr Ressourcen.
    • Ein Cross-Compiler selbst ist leicht, aber die Build-Skripte von Zehntausenden Paketen anzupassen, bedeutet einen hohen Wartungsaufwand.

  • Es gibt auch die Meinung: „Kann man nicht einfach auf einem x86_64-Server cross kompilieren?“

    • Aber alle Software so anzupassen, dass sie Cross-Compilation vollständig unterstützt, ist ein enormer Aufwand.

  • Vor einem Jahr sah ich auf Mastodon einen Beitrag mit der Aussage, dass „die schnellste RISC-V-Hardware langsamer ist als QEMU“.
    RISC-V breitet sich zwar in viele Bereiche aus, ist im High-Performance-Computing aber weiterhin schwach.

    • Der Milk-V Pioneer hat diese Grenze zwar überschritten, ist aber teuer, und auch die verwendete Architektur ist alt.
      Zudem ist der Entwickler wegen US-Sanktionen vom Markt verschwunden.

  • Cross-Compilation ist nicht unmöglich, aber in den Phasen %install und %check wird die Testausführung zum Problem.
    Zum Beispiel mussten im PR für das Paket rpy auf RISC-V Vektortests deaktiviert werden.
    Man kann Build und Tests trennen, aber gemessen an der zusätzlichen Komplexität spart das nicht viel Zeit.

    • Fedora bevorzugt traditionell Native Builds.
      Schon im LWN-Thread von 2012 (Link) wurde gegen Cross-Compilation argumentiert.
    • Der Build mit QEMU ist die praktikabelste Alternative.

  • Das Ergebnis, dass i686 um 14 % schneller sei als x86_64, wirkt fragwürdig.
    Normalerweise ist x86_64 schneller, vor allem dank der größeren Zahl an Registern und der Vektor-Instruktionen.
    Allerdings versucht der Compiler dadurch möglicherweise auch mehr Optimierungen, was die Build-Zeit verlängern kann.
    Bei RISC-V könnte es ein ähnliches Phänomen geben.

    • Wenn i686 schneller ist, könnte das an einem Speicherbandbreiten-Flaschenhals liegen.
    • x86_64-Builds haben 50 % mehr Linker-Tests als i686.

  • Im Artikel wird nicht angegeben, welche RISC-V-CPU verwendet wurde, daher bleibt der Vergleich vage.

    • In der Praxis bestehen die meisten Builder aus 4 bis 8 Kernen und 8 bis 32 GB RAM; die Auswahl ist nicht groß.
      Der Milk-V Pioneer ist mit 64 Kernen und 128 GB RAM eine Ausnahme, nutzt aber eine ältere Architektur und ist teuer.