RISC-V est beaucoup trop lent

 (marcin.juszkiewicz.com.pl)
3 points par GN⁺ 2026-03-24 | 1 commentaires | Partager sur WhatsApp
  • Le portage RISC-V de Fedora Linux est en cours depuis environ 3 mois, et la plupart des paquets ont déjà été compilés pour Fedora 43
  • Le matériel RISC-V actuel affiche des vitesses de compilation extrêmement lentes, avec jusqu’à plus de 5 fois le temps nécessaire par rapport à x86_64 pour compiler le même paquet
  • Pour être adopté comme architecture officielle de Fedora, il faut un matériel de classe serveur capable de compiler binutils en moins d’une heure
  • Les retards de compilation provoquent le mécontentement des mainteneurs de paquets, et l’éventualité d’une exclusion de RISC-V est également évoquée
  • À l’avenir, Fedora prévoit le démarrage des builds Fedora 44 et l’introduction de builders plus rapides afin d’améliorer les problèmes de vitesse, tout en maintenant l’unification du noyau et la désactivation de LTO

État d’avancement du portage Fedora RISC-V

  • Le portage RISC-V de Fedora Linux est en cours depuis environ 3 mois, avec plusieurs changements survenus entre-temps
  • La plupart des éléments du tracker Fedora RISC-V ont été traités, et seuls 17 éléments restent actuellement à l’état NEW
  • Les sources des paquets Fedora sont récupérées puis compilées avec la commande fedpkg mockbuild -r fedora-43-riscv64
  • Jusqu’à présent, 86 Pull Requests portant sur des paquets ont été soumises, la plupart ont été fusionnées, et les builds pour Fedora 43 sont terminés
  • Il est possible de poursuivre les builds supplémentaires en suivant le tag ‘f43-updates’

  • Problème de vitesse de compilation sur RISC-V

    • Le matériel RISC-V affiche actuellement des vitesses de compilation extrêmement lentes
    • Le temps de compilation de binutils 2.45.1-4.fc43 a été mesuré à 143 minutes sur riscv64, 36 minutes sur aarch64 et 29 minutes sur x86_64
    • La carte StarFive VisionFive 2 utilisée offre une bonne prise en charge des pilotes, mais reste lente
    • La compilation du même paquet sur la carte Milk-V Megrez a pris 58 minutes
    • Les builds RISC-V actuels sont effectués avec LTO (optimisation au moment de l’édition des liens) désactivé, afin de réduire l’usage mémoire et le temps de compilation
    • Les builders disposent de 4 à 8 cœurs et de 8 à 32 Go de RAM, avec des performances évaluées au niveau d’un Arm Cortex-A55
    • À l’avenir, on attend des améliorations grâce au SoC UltraRISC UR-DP1000 (jusqu’à 64 Go de RAM) et à des systèmes basés sur SpacemiT K3 (jusqu’à 32 Go de RAM)

  • Conditions d’intégration comme architecture officielle de Fedora

    • Pour être inclus comme architecture officielle de Fedora, il faut un matériel capable de compiler le paquet binutils en moins d’une heure
    • Il faut aussi garantir une vitesse comparable à celle des autres architectures, même avec LTO activé à l’échelle du système
    • Comme les résultats de build ne sont publiés dans le dépôt qu’une fois toutes les architectures terminées, des builders lents provoquent le mécontentement des mainteneurs de paquets
    • Par le passé, des plaintes avaient déjà émergé à cause de la lenteur des builders AArch64, et certains développeurs ont évoqué la possibilité d’exclure RISC-V
    • À l’avenir, les builders devront être des systèmes de type serveur montables en rack et administrables à distance ; un environnement à base de SBC nécessitant des redémarrages manuels n’est pas adapté
    • Si ces conditions ne sont pas remplies, l’adoption de RISC-V 64 bits comme architecture officielle de Fedora sera impossible

  • Tests locaux avec QEMU

    • Étant donné la longueur des temps de compilation, les tests locaux via l’émulation QEMU sont utiles
    • Sur un desktop AArch64 de 80 cœurs, l’émulation riscv64 en espace utilisateur via QEMU permet de compiler le paquet llvm15 en environ 4 heures
    • La compilation du même paquet sur un builder Banana Pi BPI-F3 prend 10,5 heures
    • Comme le paquet LLVM exploite à la fois les cœurs et la mémoire, on attend un gain de performances sur des systèmes basés sur Ampere One à 192/384 cœurs
    • QEMU n’est utilisé que pour les builds et tests locaux, Fedora n’effectuant que des builds natifs

  • Plan pour la suite

    • Le démarrage des builds Fedora Linux 44 est prévu
    • L’objectif est d’utiliser la même image de noyau sur tous les builders, alors qu’actuellement plusieurs versions de noyau coexistent
    • LTO restera désactivé
    • Pour résoudre les problèmes de vitesse, l’introduction de nouveaux builders plus rapides est prévue, avec l’affectation de certains paquets lourds à ces builders

À lire aussi

1 commentaires

 
GN⁺ 2026-03-24
Commentaires sur Hacker News

  • Je pense qu’au lieu d’accuser l’ISA elle-même, le problème vient surtout de l’implémentation en silicium et du logiciel qui manque d’optimisations spécifiques à l’architecture
    RISC-V finira de toute façon par progresser
    ARM aussi était d’abord orienté vitesse, puis s’est réorienté vers l’efficacité énergétique pour réussir dans l’embarqué, et semble aujourd’hui revenir vers une logique axée sur les performances

    • Dans certains cas, on peut considérer que la spécification ISA de RISC-V elle-même pose problème
      Par exemple, il y a des cas comme l’issue LLVM #150263, #141488
      Il y a aussi le fait que la taille de page est figée à 4KiB, ce qui limite les performances par rapport à ARM
    • Il est difficile d’être d’accord avec l’idée que « RISC-V finira bien par rattraper son retard »
      ARM a été rapide, puis plus lent, puis à nouveau rapide, mais RISC-V n’a encore jamais montré de réelle compétitivité dans le hautes performances
      Les implémentations créées par de petites équipes sont impressionnantes, mais pour le mobile, le desktop ou les serveurs, cela reste insuffisant
    • Dire que « ce n’est pas l’ISA mais l’implémentation » est vrai, mais c’est aussi une évidence
      En pratique, l’essentiel se joue dans la structure du cache et dans la conception VLSI analogique des interfaces DDR et PCI, et il n’y a presque aucune équipe qui fasse ça correctement
      En plus, toutes les entreprises veulent devenir des « vendeurs RISC-V haute performance », mais personne ne veut s’occuper du « marché de l’embarqué »
      Aux États-Unis, on est dans un modèle où l’on vend surtout de l’IP plutôt que de fabriquer directement des puces, si bien qu’en pratique il faut dépendre de vendeurs chinois pour obtenir du vrai matériel
    • Quand on regarde l’évolution des performances CPU, on voit souvent un cycle où l’on optimise d’abord l’efficacité énergétique, puis où l’on augmente la vitesse
      L’exemple classique est celui de l’architecture Netburst du Pentium 4, arrivée à ses limites, puis remplacée comme pilier d’Intel par l’architecture Core dérivée de cœurs basse consommation
      L’histoire d’ARM suit une trajectoire assez comparable
    • Dans une vidéo de LowSpecGamer, il est raconté que les premières puces ARM fonctionnaient rien qu’avec les diodes de protection
      Selon Steve Furber, elles étaient si efficaces que du code pouvait s’exécuter alors qu’on avait oublié de brancher l’alimentation

  • Partage d’une correction à un billet de blog écrit par un collègue
    Sur le système de build Fedora RISC-V, la compilation de binutils sur un Milk-V “Megrez” a été terminée en 67 minutes, soit une nette amélioration par rapport au précédent record de 143 minutes
    Les cartes de développement les plus rapides actuellement ne sont pas les Banana Pi, mais les SiFive “HiFive P550” et UltraRISC “DP1000”
    La présentation FOSDEM “Fedora on RISC-V: state of the arch” aborde aussi ces benchmarks
    Les tests de Marcin ont été effectués sur une StarFive “VisionFive 2”, une carte stable mais plutôt lente

    • La VisionFive 2 est fiable, mais comme c’est une carte vieille de plus de 3 ans, elle atteint ses limites mémoire pour les builds récents
      Pour compiler gcc en liant 4 binaires simultanément, il faut au moins 16GB, avec du swap activé pour rester stable
      Sur la VisionFive 2, il faut donc compiler en -j1 ou -j2, ce qui allonge le temps d’un facteur 2 à 4
      Utiliser un meilleur linker (à la place de ld), ou pouvoir définir séparément le nombre de liens parallèles comme dans le système de build LLVM, serait plus efficace

  • Il a fallu 40 ans à ARM pour arriver là où il est aujourd’hui, et RISC-V n’existe encore que depuis 15 ans
    Cette année, Tenstorrent devrait lancer une plateforme serveur basée sur RVA23, donc cela vaut la peine de suivre ça
    Au final, la clé sera que les vendeurs de matériel sortent du silicium haute performance

    • RISC-V a beaucoup été influencé par MIPS, qui avait lui aussi suscité de grands espoirs au début des années 1990 avant de finalement perdre du terrain sur le marché
    • AArch64 n’a que 15 ans, mais c’est une architecture presque totalement différente du ARM 32 bits

  • felix construit actuellement le dépôt Arch Linux RISC-V avec un Milk-V Pioneer
    Je pense que le ralentissement du développement est aussi dû aux sanctions contre SOPHGO
    Le Milk-V Oasis basé sur le SG2380 de SOPHGO a vu sa sortie annulée, alors que c’était un SoC très prometteur
    Les puces de cette société prenaient en charge une double architecture capable de basculer entre ARM et RISC-V
    Voir le dépôt Arch RISC-V et cet article associé

    • Je me demande si quelqu’un pourrait expliquer concrètement quelles sanctions ont eu quels effets réels

  • Je me demande pourquoi il faut absolument compiler le logiciel RISC-V sur un système RISC-V
    Comme le compilateur incorpore les informations de l’architecture cible dans le code, on pourrait théoriquement le faire depuis un autre système, non ?

    • Pour cross-compiler toute une distribution, il faut que cette distribution le prenne en charge
      Fedora ne prend actuellement en charge que les builds natifs, et ses cross-compilateurs ne concernent que des versions bare-metal pour le firmware
      En plus, l’automatisation des tests est difficile, donc faire des builds natifs testés sur du vrai matériel reste plus réaliste
      AArch64 aussi était lent à ses débuts, mais aujourd’hui un build de Qt4 se termine en 18 minutes
    • Il y a beaucoup de problèmes de dépendances où les scripts de build consultent les bibliothèques ou la configuration de l’OS hôte
      On peut résoudre ça selon les langages, mais l’écosystème C/C++ est particulièrement complexe
      C’est pourquoi la plupart des gens compilent dans une VM ou sur le matériel cible réel
    • Les anciens compilateurs choisissaient le backend au moment de la compilation, donc le support multi-architecture était difficile
      C’est devenu possible avec LLVM, mais il faut toujours un émulateur pour les tests
    • Le cross-build lui-même est possible, mais les tests après build demandent encore plus de ressources
    • Le cross-compilateur lui-même est simple, mais il faut modifier les scripts de build de dizaines de milliers de paquets, donc la charge de maintenance est énorme

  • Certains avancent aussi : « Il suffit de cross-compiler sur un serveur x86_64, non ? »

    • Mais modifier tout le logiciel pour prendre parfaitement en charge le cross-compiling représente un travail colossal

  • Il y a un an, j’ai vu sur Mastodon un message disant que « le matériel RISC-V le plus rapide est plus lent que QEMU »
    RISC-V se diffuse certes dans de nombreux domaines, mais reste encore faible en calcul haute performance

    • Le Milk-V Pioneer a dépassé cette limite, mais il est cher et l’architecture utilisée est ancienne
      En plus, le développeur a disparu à cause des sanctions américaines

  • Le cross-compiling n’est pas impossible, mais l’exécution des tests aux étapes %install et %check pose problème
    Par exemple, dans la PR du paquet rpy, il a fallu désactiver les tests vectoriels sur RISC-V
    On peut séparer build et tests, mais le gain de temps ne compense pas vraiment la complexité supplémentaire

    • Fedora a traditionnellement préféré les builds natifs
      En 2012 déjà, dans un fil LWN (lien), il y avait des discussions opposées au cross-compiling
    • Les builds via QEMU sont l’alternative la plus réaliste

  • Le résultat affirmant que i686 est 14 % plus rapide que x86_64 semble douteux
    En général, x86_64 est plus rapide, notamment grâce au nombre accru de registres et aux instructions vectorielles
    Cela dit, comme le compilateur tente davantage d’optimisations, les temps de build peuvent aussi s’allonger
    Il est possible qu’un phénomène similaire existe sur RISC-V

    • Si i686 est plus rapide, cela peut venir d’un goulot d’étranglement de bande passante mémoire
    • Les builds x86_64 ont 50 % de tests de linker en plus que i686

  • Le texte ne précise pas quel CPU RISC-V a été utilisé, ce qui rend la comparaison ambiguë

    • En pratique, la plupart des builders sont en configuration 4 à 8 cœurs avec 8 à 32GB de RAM, et il n’y a pas beaucoup d’options
      Le Milk-V Pioneer fait exception avec ses 64 cœurs et 128GB de RAM, mais son architecture est ancienne et son prix élevé