krabby: Einen schnellen Rust-Compiler bauen

 (bal-e.org)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Krabby ist eine leistungsorientierte Rust-Compiler-Implementierung auf der grünen Wiese, die die langsame Kompiliergeschwindigkeit von rustc verbessern soll
  • Spürbare Leistungsverbesserungen bei rustc ergeben sich inzwischen eher aus Änderungen an APIs und Datenstrukturen als aus Änderungen an einzelnen Funktionen, doch wegen der großen Codebasis und der Stabilitätsanforderungen sind umfassende Änderungen schwer umzusetzen
  • Krabby versucht in einer kleinen, von einer einzelnen Person kontrollierten Codebasis, ohne Stabilität zu priorisieren, Compiler-Komponenten gemeinsam neu zu entwerfen, um neue Optimierungsmöglichkeiten und eine kohärentere Architektur zu finden
  • Ziel ist es, die Hypothese zu testen, dass man für deutlich bessere Compiler-Performance das Design vollständig neu denken muss, selbst bei einer so komplexen Sprache wie Rust
  • Der Code ist im krabby-Repository auf Codeberg öffentlich verfügbar, und Fortschrittsberichte sollen mindestens alle 1–2 Wochen im Fediverse erscheinen

Ziele und Hintergrund von Krabby

  • Rust ist die bevorzugte Sprache, aber der rustc-Compiler ist deutlich langsam
  • Viele Menschen arbeiten bereits an der Performance von rustc, und Verbesserungen, die die wahrgenommene Geschwindigkeit durch Änderungen an einzelnen Funktionen erhöhen, sind weitgehend bereits umgesetzt
  • Bedeutende Verbesserungen kommen nun eher aus Änderungen an APIs und Datenstrukturen, aber in einer großen Codebasis wie rustc sind umfassende Änderungen wegen paralleler Feature-Entwicklung und Stabilitätsanforderungen praktisch schwer realisierbar
  • Krabby ist eine leistungsorientierte Rust-Compiler-Implementierung auf der grünen Wiese und verfolgt grundlegend andere Ziele als rustc
  • Da es sich um eine kleine, von einer einzelnen Person kontrollierte Codebasis handelt und Stabilität nicht priorisiert wird, besteht der Ansatz darin, alle Komponenten mit Blick aufeinander zu entwerfen, um neue Optimierungsmöglichkeiten zu finden und eine kohärentere Architektur zu schaffen
  • Ausgangspunkt ist die Hypothese, dass man das Compiler-Design vollständig neu denken muss, um die Compiler-Performance deutlich zu verbessern
  • Es soll gezeigt werden, dass groß angelegte Architektur-Optimierungen unabhängig von der Zielsprache verborgen liegen können und nicht nur auf einfache Sprachen wie C, sondern auch auf komplexe Sprachen wie Rust anwendbar sind
  • Selbst wenn das resultierende Design speziell auf Rust zugeschnitten sein sollte, wird der Lernwert des Prozesses als hoch eingeschätzt

Projektstatus und öffentliche Materialien

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Lobste.rs-Kommentare

  • Offenbar wollen alle ihre eigene Vanity-Lizenz haben: https://codeberg.org/bal-e/krabby/…

    • Für ein Hobbyprojekt ist das vielleicht okay, aber es signalisiert schon, dass dieses Projekt eher ein casual Projekt als etwas Ernsthaftes ist
      Diese Lizenz erlaubt die kostenlose Nutzung und Weitergabe für persönliche und nichtkommerzielle Zwecke, verlangt aber, dass auch darauf aufbauende Software unter denselben Bedingungen weitergegeben wird, und für kommerzielle Zwecke ist nur eine 30-tägige Testnutzung erlaubt
      Ich frage mich, ob Codeberg bei Projektlizenzen strenge libre/Open-Source-Bedingungen verlangt. Ich dachte, Codeberg hostet nur FOSS, deshalb hat mich die Einschränkung auf nichtkommerzielle Nutzung überrascht, aber vielleicht bin ich beim aktuellen Stand nicht mehr ganz auf dem Laufenden
    • Ja, das weiß ich auch ... ich zerbreche mir wegen der Lizenzfrage schon seit ziemlich langer Zeit den Kopf und überlege, auf AGPL umzusteigen, solange ich noch alleine daran arbeite

  • Rust ist groß. Dieses Projekt wirkt ein wenig einfacher als „einen Webbrowser selbst bauen“, aber auf keinen Fall einfach. Trotzdem rechne ich ihm das große Ziel hoch an
    Wenn man sich krabby: motivations ansieht, scheint Geschwindigkeit der Hauptgrund für dieses Projekt zu sein
    Nach meinem Verständnis von Rust sind Typprüfung, Borrow-Checking usw. bereits sehr schnell, und der Flaschenhals ist die Codegenerierung, wobei ein erheblicher Teil davon eher mit LLVM als mit Rust selbst zusammenhängt
    Ich frage mich, wie es derzeit rund um Cranelift aussieht und ob es Überschneidungen mit Ideen gibt, die die Codegenerierung beschleunigen sollen

    • Diese Annahme setzt voraus, dass die Gesamtarchitektur von rustc+LLVM passt und jetzt nur noch konstante Faktoren wichtig sind
      Ich bin persönlich ziemlich überzeugt, dass das keinen Sinn ergibt, wenn man die Compiler-Pipeline als Ganzes betrachtet. Wir brauchen MIR-only rlib und ein Backend, das Whole-World-Optimierung ohne unendlich viel RAM kann (siehe diesen Kommentar)
      „Codegen Unit“ ist reine versehentliche Komplexität
    • Das hängt davon ab, was man genau macht: Depends on what exactly you're doing
      Vor allem die konkrete Aufschlüsselung für libraries und binaries könnte interessant sein
      LLVM ist zwar nicht gerade schnell, aber soweit ich mich erinnere, half es auch nicht, dass rustc LLVM tendenziell ein etwas aufgeblähtes IR übergibt
    • Danke :) Bei Rust-Kompilierzeiten scheinen die Perspektiven ziemlich auseinanderzugehen. Manche geben der Typprüfung die Schuld, andere LLVM
      Mein mittelfristiges Ziel, also mein Ziel für die nächsten etwa fünf Jahre, ist cargo check, daher fasse ich die Codegenerierung nicht an
      Ich denke trotzdem, dass es noch viel Spielraum für Optimierungen gibt, etwa bei besserer Parallelität, der Auslagerung heißer Pfade im Diagnosecode, weniger doppelter Arbeit zwischen Typprüfung und Borrow-Checking sowie einer besseren Speicheranordnung zentraler Datenstrukturen
      Es hilft auch, dass ich mit rustc-Entwicklern befreundet bin und daher oft von verschiedenen Problemen im Codebestand höre
    • Für rustc gibt es ein Cranelift-Backend
    • LLVM scheint tatsächlich der langsame Teil zu sein. Dieses Muster habe ich auch in Diskussionen über Zig-Kompilierzeiten gesehen, und die selbst gehostete Gegenstück-Implementierung ist deutlich schneller als LLVM 1