ナイトリービルドで並列フロントエンドにより Rust のコンパイルを高速化

Rust コンパイラの並列フロントエンドで高速なコンパイルが可能に

• Rust コンパイラのフロントエンドは並列実行を利用して、コンパイル時間を大幅に短縮できる。
• 並列フロントエンドは実験的機能であり、-Z threads=8 オプションを使ってナイトリーコンパイラで試せる。
• 2024年に安定版コンパイラとしてリリースされる予定。

コンパイル時間と並列性

• Rust のコンパイル時間は継続的な関心事であり、コンパイラ性能ワーキンググループは何年にもわたってコンパイラ性能を着実に改善してきた。
• 2023年の最初の10か月で、コンパイル時間は平均13%、メモリ使用量は15%、バイナリサイズは7%減少した。
• コンパイラはすでに大きく最適化されており、新たな改善点を見つけるのは難しくなっているが、並列性は大きな効果が期待できる一方で難しい改善項目として残っている。

既存のプロセス間並列性

• Rust プログラムをコンパイルするとき、Cargo は複数の rustc プロセスを並列に実行して複数のクレートをコンパイルする。
• クレート間の依存関係が少ないと並列実行はうまく機能するが、依存関係が増えるにつれて並列実行の度合いは下がる。

既存のプロセス内並列性: バックエンド

• コンパイラはフロントエンドとバックエンドに分かれており、バックエンドはコード生成を担当し、LLVM がこれを並列に処理する。
• フロントエンドはパースや型チェックなどを行うが、今週までは並列実行を利用できなかった。

新しいプロセス内並列性: フロントエンド

• フロントエンドは теперь Rayon を使って、細粒度の並列性でコンパイル作業を実行できるようになった。
• 並列フロントエンドを有効にし、8スレッドを使う設定にすると、フロントエンドの実行時間が大きく短縮されることが確認できる。

全体としての組み合わせ

• Rust のコンパイルは長らく、Cargo によるプロセス間並列性とバックエンドのプロセス内並列性の恩恵を受けてきたが、 теперь フロントエンドでもプロセス内並列性の恩恵を受けられる。
• コンパイラは jobserver プロトコルを使って生成されるスレッド数を制限し、コア数を超えないようにしている。

使用方法

• ナイトリーコンパイラは並列フロントエンドを有効化した状態でリリースされたが、デフォルトではシングルスレッドモードで動作する。
• 利用者は -Z threads オプションを使ってマルチスレッドモードに切り替えられる。

性能への影響

• シングルスレッドモードで並列フロントエンドを実行すると、コンパイル時間は従来より0%から2%遅くなる可能性がある。
• マルチスレッドモードではコンパイル時間が最大50%短縮される可能性があるが、効果はコードの特性やビルド構成によってさまざまだ。

正確性

• シングルスレッドモードでは高い信頼性が期待される。
• マルチスレッドモードでは既知のバグやデッドロックがある可能性があり、コンパイラが生成するバイナリはどのフロントエンドを使っても同一であるべきだ。

フィードバック

• 並列フロントエンドに問題がある場合は、"WG-compiler-parallel" ラベルの付いた issue を確認し、新しい issue を提出できる。

今後の作業

• 並列フロントエンドの性能改善と、マルチスレッドモードのバグ修正が進行中。
• 2024年には -Z threads オプションを安定化し、安定版リリースでデフォルトでマルチスレッドモードで動作するようにする計画。

GN⁺ の意見

この記事で最も重要なのは、Rust コンパイラのフロントエンドが теперь 並列実行をサポートし、コンパイル時間を大幅に短縮できるようになったことだ。これは Rust 開発者にコンパイル速度向上という大きな利点をもたらし、効率的な開発環境づくりに貢献するだろう。並列フロントエンドの導入は Rust コミュニティにとって興味深いニュースであり、性能改善に向けた継続的な取り組みの成果といえる。

[GN⁺]

Hacker Newsの意見

• Rustのコンパイル速度改善への期待
  • Rustはコンパイル速度の遅さが欠点として指摘されており、特に大規模リポジトリで作業する際にはCI/CDコストの増加や開発時間の遅延の原因になる。キャッシュを削除しなければならないとき（Dockerのバグでたまに発生する）には特に問題になる。この進展に対して前向きな反応。
• Rustのコンパイル速度に関する個人的な経験
  • かなり前にRustを使っていたときはコンパイル速度が遅かったが、最近また使い始めてからはコンパイル時間をほとんど気にしなくなった。ただし、プロジェクトが大きくなるにつれてコンパイルの遅延を感じることがあり、この改善は個人的にとてもうれしいニュース。
• Rustのコンパイル過程に関する質問
  • Rustのフロントエンドは借用チェックを終えてからでないとバックエンドが作業を開始できないのか、という質問。バックエンドが借用チェックのエラーを見つけた場合、推測的な作業を捨てられるのではないかという疑問。
• Rustバイナリクレートのコンパイルに関する観察
  • ライブラリクレートとは異なり、バイナリクレートは基本的に大きく単一構造になりがちで、コンパイルが並列化されず、最も大きいクレートが直列化される傾向がある。この問題への改善は歓迎される。
• CPUコア活用に関する質問
  • コンパイル時にCPUコア数を自動で使えるようにできるのか、それとも別のマシンでも使われる設定ファイルに固定値を入れなければならないのか、という質問。
• マルチスレッドモードのバグに関する警告
  • マルチスレッドモードには既知のバグやデッドロックがあり、コンパイルが止まった場合はそのどれかに遭遇した可能性がある。-Z threadsオプションの使用には慎重な姿勢。
• Rustコンパイル速度の現在の状態に対する肯定的な評価
  • 数年間Rustを使っていなかったが、最近また使ってみるとコンパイル速度はほとんど即時に感じられる。ChatGPTのようなツールを使うことで、以前は解決しにくかったRustの問題も簡単に解決できるようになり、現在の状態は非常に良い。
• Rustコンパイル最適化の方向性に関する疑問
  • Rustのコンパイルはすでにファイルレベルで高度に並列化されているのに、単一ファイルのコンパイル速度を上げることが、より上位レベルのファイル並列化からリソースを奪うことにならないかと懸念している。これに関する具体的なデータがない点が問題として指摘されている。
• Rustコンパイル速度改善を歓迎するコメント