RustにCraneliftコード生成を導入

• CraneliftはApache-2.0ライセンスのコード生成バックエンドで、WebAssembly向けのWasmtimeランタイムの一部として開発された
• 2023年10月、RustプロジェクトはCraneliftをnightlyツールチェーンのオプションコンポーネントとして提供し始めた
• ユーザーは現在、Rustで書かれたプロジェクトのデバッグビルド向けコード生成バックエンドとしてCraneliftを利用できる
• Craneliftは既存のコンパイラと競合しつつ、重要な最適化のみを優先する簡素化された設計により、より高速にコードを生成する

コンパイル時間の重要性

• プログラミング言語のユーザーは高速なコンパイル時間を求めている
• RustはLLVMを使う他の言語と同様に、コンパイル時間に関する不満があった
• 十分に高速にコードを生成できるコンパイラは、インタプリタを使うより有利になりうる
• コンパイル速度を重視したコンパイラには価値がありうる

Craneliftの最適化

• Craneliftはコード生成時に複数の方法で最適化を行う
• 最適化パイプラインはE-graphに基づいており、これは中間表現の集合を効率よく表すデータ構造である
• 従来のコンパイラでは、最適化の順序が生成されるコードの品質に大きく影響する
• CraneliftはE-graphを使うことで、最適化の順序が結果に影響しないようにしている
• E-graphから最終表現を抽出することはNP-complete問題だが、Craneliftはヒューリスティックを使って十分に良い表現を高速に抽出する

Rust向けCranelift

• CraneliftをRustバックエンドとして使うためには相当な努力が必要だった
• Rustコンパイラは、型検査済みプログラムを表現するためにmid-level IRを使用する
• Craneliftを使うには、mid-level IRをCLIFへ変換するライブラリが必要だった
• このライブラリはRustコンパイラチームのメンバーである"bjorn3"によって主に書かれた
• ユーザーはrustupとcargoを使ってCraneliftバックエンドを試すことができる

GN⁺の見解

• Craneliftの導入は、Rustコミュニティにおけるコンパイル時間短縮への継続的な要望に応えるものと見なせる。これは開発者の生産性向上に貢献しうる。
• CraneliftがE-graphを使って最適化順序の問題を解決するアプローチは、コンパイラ設計における新たなパラダイムを提示している。これはコンパイラ研究および開発に新しい方向性を示しうる。
• 批判的な観点では、CraneliftがLLVMと比べてどれほど安定的かつ効率的かは、今後さらに多くの実運用事例を通じて検証される必要がある。
• Craneliftと似た機能を提供する他のコンパイラバックエンドにはGCCのlibgccjitなどがあり、こうした代替手段との比較を通じてCraneliftの長所と短所をより明確に把握できる。
• Craneliftを導入する開発者は、既存のLLVMベースのインフラとの互換性や移行コストを考慮し、Craneliftの性能と安定性を慎重に評価する必要がある。

[GN⁺]

Hacker Newsの意見

• バックエンドと最適化は、異なるクレート（crates）ごとに使い分けることができる。依存関係には最適化されたLLVMビルドを使い、自分のコードにはデバッグ用LLVMやCraneliftを使うのがしばしば理にかなっている。
• 最適化速度と最適化品質のトレードオフについて優れた概要を提供する記事。特に、事前コンパイル済みコードを使うcopy-and-patchコンパイルは依然として最速だが、最適化の余地は小さい。CraneliftはIR内の等価性を表現するためにe-graphsを使い、copy-and-patchアプローチよりも多くの最適化を可能にしている。最も最適化された出力はLLVMやGCCのような伝統的なコンパイラツールチェーンから得られるだろうが、「十分に速い」出力をできるだけ早く得たいユーザーにとっては、新しいコンパイラ技術が有望な代替手段を提供している。
• フルデバッグビルドに関するコメントは多いが、小さな変更に対する増分ビルド時間こそが最も重要な違いだと思う。これが開発の反復を高速化する。rust-analyzerとgleamプロジェクトで小さな変更をした後のビルド時間を比較すると、Craneliftとmoldを追加した場合のほうがはるかに大きな改善を示した。Go言語でビルドされたTerraformと比べても、Rustの大きな改善が見て取れる。
• 現時点ではM1-M3 Macのサポートがなく、Windowsサポートもないようだ。最も活発なコントリビューターによる最新の更新でも結論は曖昧だ。Windowsサポートは現在省かれており、macOSは今のところx86_64のみをサポートしている。M1プロセッサを使っている場合は、x86_64版のrustcをインストールしてRosetta 2を試せるが、Rosetta 2は性能に影響する可能性があるため、LLVMバックエンドと比較してみる必要がある。
• Bevyプロジェクトで記事の手順を試し、「通常の」ビルドと比較した。Cranelift+debugビルドと比べてリリースビルドのほうが速いように見えるが、それはsccacheとローカルNASを使ってキャッシュしているためだ。キャッシュなしでデバッグビルドだけを再度試したところ、コンパイル時間はほぼ半分に減った。
• Equality GraphsのリンクからESC/Javaを知った。実際にESC/Javaを試したことがある人や、うまく使えた人がいるのか気になる。Spot bugs（以前はFindbugsとして知られていたもの）と比較すると興味深そうだ。
• Craneliftを使ったデバッグビルドが開発の反復速度を高めてくれることに大いに期待している。特にWASM/フロントエンドRustでは反復速度が重要で、Rustツールの新時代は時に1秒未満のビルドを実現する。まだARM macOSをサポートしていないため、M1-3ユーザーは少し待つ必要がある。
• Cranelift使用時のランタイム（コンパイル時間ではなく）のベンチマークがあるのか気になる。記事では「2倍遅い」と言及されていたが、そのデータは2020年時点のものだ。それ以降かなり改善されたのか知りたい。
• なぜCraneliftがLLVMより速いと期待されるのか、またその改善がなぜLLVMにも適用できないのかを説明できる人がいるのか気になる。