Einführung der Cranelift-Codegenerierung in Rust

• Cranelift ist ein Codegenerierungs-Backend unter der Apache-2.0-Lizenz, das als Teil der Wasmtime-Laufzeit für WebAssembly entwickelt wurde
• Im Oktober 2023 begann das Rust-Projekt, Cranelift als optionale Komponente der Nightly-Toolchain bereitzustellen
• Nutzer können Cranelift nun als Codegenerierungs-Backend für Debug-Builds von in Rust geschriebenen Projekten verwenden
• Cranelift konkurriert mit bestehenden Compilern und erzeugt durch ein vereinfachtes Design, das nur wichtige Optimierungen priorisiert, schneller Code

Die Bedeutung von Compile-Zeiten

• Nutzer von Programmiersprachen wünschen sich schnelle Compile-Zeiten
• Rust hatte wie andere Sprachen, die LLVM verwenden, Beschwerden über die Compile-Zeit
• Ein Compiler, der schnell genug Code erzeugt, kann gegenüber der Nutzung eines Interpreters im Vorteil sein
• Ein auf Compile-Geschwindigkeit fokussierter Compiler kann wertvoll sein

Optimierungen in Cranelift

• Cranelift führt bei der Codegenerierung auf verschiedene Weise Optimierungen durch
• Die Optimierungs-Pipeline basiert auf E-graphs, einer Datenstruktur zur effizienten Darstellung von Mengen von Zwischendarstellungen
• In traditionellen Compilern hat die Reihenfolge der Optimierungen großen Einfluss auf die Qualität des erzeugten Codes
• Cranelift nutzt E-graphs, damit die Reihenfolge der Optimierungen das Ergebnis nicht beeinflusst
• Das Extrahieren der finalen Darstellung aus einem E-graph ist ein NP-complete-Problem, aber Cranelift verwendet Heuristiken, um schnell eine ausreichend gute Darstellung zu extrahieren

Cranelift für Rust

• Der Aufwand, Cranelift als Rust-Backend zu verwenden, war beträchtlich
• Der Rust-Compiler verwendet ein Mid-Level-IR, um typgeprüfte Programme darzustellen
• Um Cranelift zu verwenden, war eine Bibliothek nötig, die das Mid-Level-IR in CLIF umwandelt
• Diese Bibliothek wurde hauptsächlich von "bjorn3", einem Mitglied des Rust-Compiler-Teams, geschrieben
• Nutzer können das Cranelift-Backend mit rustup und cargo ausprobieren.

Meinung von GN⁺

• Die Einführung von Cranelift kann als Reaktion auf die anhaltende Forderung in der Rust-Community nach kürzeren Compile-Zeiten gesehen werden. Das kann zur Steigerung der Produktivität von Entwicklern beitragen.
• Der Ansatz von Cranelift, das Problem der Optimierungsreihenfolge mithilfe von E-graphs zu lösen, stellt ein neues Paradigma im Compiler-Design vor. Das könnte neue Richtungen für Compiler-Forschung und -Entwicklung aufzeigen.
• Aus kritischer Perspektive muss sich in weiteren realen Einsatzszenarien noch zeigen, wie stabil und effizient Cranelift im Vergleich zu LLVM ist.
• Andere Compiler-Backends mit ähnlicher Funktionalität wie Cranelift sind unter anderem GCCs libgccjit; ein Vergleich mit solchen Alternativen kann die Vor- und Nachteile von Cranelift klarer machen.
• Entwickler, die Cranelift einführen, sollten die Kompatibilität mit bestehender LLVM-basierter Infrastruktur sowie die Umstellungskosten berücksichtigen und Leistung und Stabilität von Cranelift sorgfältig bewerten.

[GN⁺]

Hacker-News-Kommentare

• Backend und Optimierung können für unterschiedliche Crates verschieden eingesetzt werden. Für Abhängigkeiten kann es sinnvoll sein, einen optimierten LLVM-Build zu verwenden und für den eigenen Code Debug-LLVM oder Cranelift.
• Ein Artikel mit einem hervorragenden Überblick über die Geschwindigkeit von Optimierungen im Verhältnis zu deren Qualität. Insbesondere ist Copy-and-Patch-Kompilierung mit vorab kompiliertem Code weiterhin am schnellsten, lässt aber wenig Spielraum für Optimierungen. Cranelift verwendet e-graphs, um Gleichwertigkeit im IR darzustellen, und ermöglicht dadurch mehr Optimierungen als der Copy-and-Patch-Ansatz. Die am stärksten optimierte Ausgabe wird zwar weiterhin aus traditionellen Compiler-Toolchains wie LLVM oder GCC kommen, aber für Nutzer, die möglichst schnell eine „schnell genug“-Ausgabe erhalten wollen, bieten neue Compiler-Techniken eine vielversprechende Alternative.
• Es gibt viele Kommentare zu vollständigen Debug-Builds, aber ich denke, der wichtigste Unterschied ist die Zeit für inkrementelle Builds bei kleinen Änderungen. Das beschleunigt die Entwicklungsiteration. Beim Vergleich der Build-Zeiten nach kleinen Änderungen in rust-analyzer und im gleam-Projekt zeigte das Hinzufügen von Cranelift und mold deutlich größere Verbesserungen. Selbst im Vergleich zu Terraform, das in Go gebaut wurde, zeigt sich eine große Verbesserung für Rust.
• Unterstützung für M1-M3-Macs gibt es derzeit nicht, und es scheint auch keine Windows-Unterstützung zu geben. Das jüngste Update des aktivsten Mitwirkenden bleibt im Fazit unklar. Windows-Unterstützung wurde derzeit weggelassen, und unter macOS wird momentan nur x86_64 unterstützt. Wer einen M1-Prozessor verwendet, kann versuchen, die x86_64-Version von rustc zu installieren und Rosetta 2 zu nutzen, sollte aber bedenken, dass Rosetta 2 die Leistung beeinflussen kann, sodass ein Vergleich mit dem LLVM-Backend sinnvoll ist.
• Im Bevy-Projekt wurden die Anweisungen aus dem Artikel ausprobiert und mit einem „normalen“ Build verglichen. Im Vergleich zu einem Cranelift+debug-Build scheint ein Release-Build schneller zu sein, was aber am Caching mit sccache und einem lokalen NAS liegt. Als nur der Debug-Build ohne Caching erneut getestet wurde, sank die Kompilierzeit auf fast die Hälfte.
• Über den Link zu Equality Graphs bin ich auf ESC/Java gestoßen. Ich frage mich, ob jemand ESC/Java tatsächlich ausprobiert hat oder damit erfolgreich war. Ein Vergleich mit Spot bugs (früher als Findbugs bekannt) wäre interessant.
• Ich freue mich sehr darauf, dass Debug-Builds mit Cranelift die Geschwindigkeit der Entwicklungsiteration erhöhen könnten. Gerade bei WASM/Frontend-Rust ist Iterationsgeschwindigkeit wichtig, und die neue Ära der Rust-Tools liefert gelegentlich Builds in unter einer Sekunde. Da ARM-macOS noch nicht unterstützt wird, müssen M1-3-Nutzer noch etwas warten.
• Ich frage mich, ob es Benchmarks zur Laufzeit (nicht zur Kompilierzeit) bei der Verwendung von Cranelift gibt. Im Artikel ist von „doppelt so langsam“ die Rede, aber diese Daten stammen aus dem Jahr 2020. Ich frage mich, ob sich das seitdem deutlich verbessert hat.
• Ich frage mich, ob jemand erklären kann, warum Cranelift voraussichtlich schneller als LLVM ist und warum diese Verbesserungen nicht auch auf LLVM angewendet werden könnten.