krabby : créer un compilateur Rust rapide

 (bal-e.org)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Krabby est une implémentation de compilateur Rust from scratch axée sur les performances, qui cherche à améliorer la lenteur de compilation de rustc
  • Dans rustc, les améliorations de performance perceptibles viennent désormais moins de la modification d’une fonction isolée que de changements d’API et de structures de données, mais ces refontes de grande ampleur sont difficiles à mener à cause de la taille du codebase et des exigences de stabilité
  • Krabby cherche, dans un petit codebase contrôlé par une seule personne et sans faire de la stabilité une priorité, à repenser ensemble les composants du compilateur afin de trouver de nouvelles opportunités d’optimisation et une architecture plus cohérente
  • L’objectif est de tester, même sur un langage complexe comme Rust, l’hypothèse selon laquelle il faut repenser entièrement la conception du compilateur pour obtenir de gros gains de performance
  • Le code est publié dans le dépôt krabby sur Codeberg, et l’objectif est de publier des avancées sur le Fediverse au moins toutes les une à deux semaines

Objectifs et contexte de Krabby

  • Rust est le langage préféré de l’auteur, mais le compilateur rustc est sensiblement lent
  • Beaucoup de personnes travaillent déjà à améliorer les performances de rustc, et la plupart des optimisations perceptibles obtenues par des modifications de fonctions isolées ont presque toutes déjà été mises en œuvre
  • Les améliorations significatives passent désormais par des changements d’API et de structures de données, mais dans un grand codebase comme rustc, elles sont en pratique difficiles à réaliser à cause du développement simultané de nombreuses fonctionnalités et des exigences de stabilité
  • Krabby est une implémentation from scratch d’un compilateur Rust dont la priorité est la performance, avec des objectifs fondamentalement différents de ceux de rustc
  • Comme il s’agit d’un petit codebase contrôlé par une seule personne et que la stabilité n’est pas prioritaire, l’approche consiste à concevoir chaque composant en tenant compte des autres afin de découvrir de nouvelles opportunités d’optimisation et de bâtir une architecture plus cohérente
  • Le projet part de l’hypothèse que, pour améliorer fortement les performances d’un compilateur, il faut repenser entièrement sa conception
  • Il cherche à montrer que de grandes optimisations architecturales peuvent rester cachées quel que soit le langage ciblé, et qu’elles peuvent s’appliquer non seulement à un langage simple comme C, mais aussi à un langage complexe comme Rust
  • Même si la conception finale s’avère spécifique à Rust, l’auteur estime que les enseignements tirés du processus auront de la valeur

État du projet et ressources publiques

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Avis sur Lobste.rs

  • On dirait que tout le monde veut sa propre licence de vanité https://codeberg.org/bal-e/krabby/…

    • Pour un projet de loisir, pourquoi pas, mais ça donne aussi le signal que ce projet est plutôt un projet casual qu’un projet vraiment sérieux
      Cette licence autorise gratuitement l’utilisation et le partage à des fins personnelles et non commerciales, mais impose que les logiciels construits dessus soient eux aussi partagés selon les mêmes conditions, et l’usage commercial n’est autorisé qu’en essai pendant 30 jours
      Je me demande si Codeberg exige des conditions strictes de type libre/open source pour les licences de projet. Je croyais que Codeberg n’hébergeait que du FOSS, donc cette restriction à l’usage non commercial m’a surpris, mais il est possible que je ne suive plus bien la situation récente
    • Oui, je sais... je réfléchis beaucoup à cette question de licence depuis un bon moment, et tant que je travaille encore seul dessus, j’envisage de passer à l’AGPL

  • Rust est vaste. Ce projet a l’air un peu plus simple que « construire soi-même un navigateur web », mais ça n’a rien de facile pour autant. Cela dit, j’apprécie l’ambition
    En lisant krabby: motivations, on a l’impression que la vitesse est la raison principale du projet
    D’après ma compréhension de Rust, la vérification de types, le borrow checking, etc. sont déjà très rapides, et le goulot d’étranglement est la génération de code, dont une bonne partie relève davantage de LLVM que de Rust lui-même
    Je me demande où en est Cranelift en ce moment, et s’il y a un recoupement avec les idées visant à accélérer la génération de code

    • Cette hypothèse suppose que l’architecture globale de rustc+LLVM est correcte et que seuls les facteurs constants comptent désormais
      Personnellement, je suis assez convaincu qu’à l’échelle de l’ensemble du pipeline de compilation, ça ne tient pas vraiment debout. Il faut des rlib dédiés au MIR, et un backend capable de faire de l’optimisation à l’échelle du monde entier sans exiger une RAM infinie (voir ce commentaire)
      Les « Codegen Unit » ne sont que de la complexité accidentelle
    • Cela dépend de ce que tu fais exactement : Depends on what exactly you're doing
      En particulier, la décomposition détaillée pour les bibliothèques et les binaires peut être intéressante
      LLVM n’est pas particulièrement rapide, mais si je me souviens bien, le fait que rustc lui passe un IR quelque peu gonflé n’a pas aidé non plus
    • Merci :) On dirait que les points de vue sur le temps de compilation de Rust varient beaucoup selon les personnes. Certains mettent en cause la vérification de types, d’autres LLVM
      Mon objectif à moyen terme, c’est-à-dire pour les cinq prochaines années environ, c’est cargo check, donc je ne touche pas à la génération de code
      Malgré tout, je pense qu’il y a encore beaucoup de marge d’optimisation, notamment sur un meilleur parallélisme, l’isolation des hot paths du code de diagnostic, la réduction du travail redondant entre vérification de types et borrow checking, ou encore l’amélioration de l’agencement mémoire des structures de données clés
      Le fait d’être proche des développeurs de rustc aide aussi, car j’entends souvent parler de divers problèmes dans la base de code
    • Il existe un backend Cranelift pour rustc
    • LLVM semble bien être la partie réellement lente. J’ai vu la même tendance dans les discussions sur les temps de compilation de Zig, et l’implémentation correspondante en self-hosted est nettement plus rapide que LLVM 1