2026年9月におけるRustコンパイラの高速化方法

2026年9月におけるRustコンパイラの高速化方法 Rustコンパイラのパフォーマンスに関する私の最後の投稿は2ヶ月前でしたが、それ以来多くのことが起こりました。全体的な進捗状況 2026年7月29日から2026年9月28日までの測定結果はここにあります。平均ウォールタイムの削減率は4.57%で、わずか2ヶ月での驚異的な改善です。629件のベンチマーク測定のうち、555件が改善し、後退したのは74件のみでした。多くのベンチマークで二桁パーセントの削減が見られました。この結果の専門用語は「緑の海」です。 rustdoc 私の最後の投稿で、Noah Lev氏がrustdocで驚異的な速度向上を達成したことに言及しました。彼は最近、それがどのように達成されたかを詳細に説明する投稿を書きました。興味深く満足のいく読み物です。 Clippy #159642：このPRで、Jakub Beránek氏はClippyにPGOを有効にし、ほとんどのClippyベンチマークでウォールタイムが改善され、最良の場合は18%も改善しました！ LLVMアップデート #158734：このPRで、Nikita Popov氏はコンパイラが使用するLLVMのバージョンをLLVM 23にアップグレードしました。LLVMをアップグレードすると、しばしば素晴らしい速度向上が見られます。全ベンチマークの平均ウォールタイム削減率は1.2%で、大したことないように聞こえるかもしれませんが、単一のPRとしては本当に印象的です。LLVMチームの素晴らしい仕事です！ 新しいborrow checker 新しいborrow checkerであるPolonius Alpha（ナポレオン・ダイナマイトとは無関係）がNightlyで有効になりました。これは既存のborrow checkerよりも正確で、古いborrow checkerでは拒否されていた一部の有効なプログラムを受け入れます。古いborrow checkerよりも多くの作業を行うため、コンパイル時間に測定可能な影響を与える場合があります。幸いなことに、Jack Huey氏がこの問題に取り組んでいます。 #161938：このPRで、Jack氏はライフネス計算を遅延させ、serdeでは3-5%、他のいくつかのベンチマークでは1%未満の命令数削減を達成しました。 #161938：このPRで、Jack氏はデータ構造を調整し、インライニングを微調整し、多くのベンチマークで命令数の削減を1%未満に抑えました。 Polonius Alphaの残りのリグレッションを減らすために、さらに作業が必要ですが、「緑の海」が示すように、これらのリグレッションは他の多くの最近の改善によってかき消されたことは注目に値します。 新しいtrait solver 新しいtrait solverであるPenelope Hammertime（編集注：これで正しいですか？）もNightlyで有効になりました。言ったように、多くのことが起こっています。新しいborrow checkerと同様に、新しいtrait solverは一部のケースでは遅くなります。Jana Dönszelmann氏は、この新しいsolverのパフォーマンスを改善するための取り組みについて詳細な投稿を書きました。Jana氏の投稿は非常に詳細なので、新しいsolverに関する多くの進行中の作業についてはあまり言及しませんが、私が作成したPRを通りすがりに言及します：#160479、#160605、#160801、#160892、#161077、#161211。これらのいくつかは、特定の外れ値クレートのコンパイル時間を大幅に削減しました：ここでは50%、あちらで25%、あちらで15%、そして一つのストレステストではさらに多くです。そして、私だけが進歩しているわけではありません… Jana氏の投稿を読んでください。 xmakro 新規貢献者のxmakro氏は、良い改善を続けました。 #157281：このPRで、xmakro氏はスペシャライゼーショングラフを構築する際のimplハンドリングを最適化しました。これは、全ベンチマークの平均サイクル数削減率を1.58%とし、単一のPRとしては非常に大きな成果です。 #158059：このPRで、xmakro氏はインクリメンタルコンパイルデータのロードの一側面を最適化し、複数のベンチマークで命令数を削減しました。最良の場合は6%でした。 #160473：このPRで、xmakro氏はホットな義務処理パスで一部の割り当てを回避し、多数のベンチマークで命令数を削減しました。最良の場合は2%でした。 #160268：このPRで、xmakro氏は古い/新しいtrait solverの選択コードを動的ディスパッチから静的ディスパッチに変更することで、多くの割り当てを回避しました。これにより、多くのベンチマークで命令数の削減が1%未満に抑えられました。このホットな割り当てパスは、以前からプロファイルに表示されており、私も以前#155714で全く同じアイデアを試しましたが、いくつかのベンチマークでリグレッションが発生しました。おそらく、一部の#[inline]属性を配置する場所の選択がわずかに異なったためでしょう。この明白な非効率性が修正されたのを見て良かったです。 データフロー分析 #160193：このPRで、コンパイラで使用されるデータフロー分析のCFGトラバーサルアルゴリズムを変更しました。これらの分析は不動点に収束し、トラバーサルアルゴリズムは不動点に到達する速度に影響を与える可能性があります。ほとんどのコードでは新しいアルゴリズムは違いを生みませんが、cranelift-codegenクレートには18,000以上の基本ブロックを持つ巨大な関数があります。古いアルゴリズムでは、borrow checkerが使用するEverInitializedPlaces分析の不動点に到達するためにapply_effects_in_blockの呼び出しが150万回必要でしたが、新しいアルゴリズムでは90,000回で済みます。これにより、このクレートのチェックビルドで約30%のウォールタイム削減が達成されました。 #160033：このPRで、EverInitializedPlacesを再び効率化しました。今回は、不要なデータをプロジェクションのために追跡しないようにしました。これにより、match-stressベンチマークで命令数が17%、他のいくつかのベンチマークで1%未満削減されました。 LLM それらは特定の種類の分析において非常に優れています。私はまだ自分のコードとテキストをすべて自分で書いていますが、（a）それが最優先事項であり、（b）プロジェクトポリシーで要求されているためです。しかし、この投稿で言及されたいくつかのPRで、有用なLLM分析支援を受けました。とにかく、それについては十分です。 その他 #160535：このPRで、Chris Denton氏はコンパイラが使用するデフォルトのスタックサイズを増やし、再帰レベルが高い場所に散在していた手動スタック拡張メカニズムであるensure_sufficient_stackを削除できるようにしました。スタック枯渇にどう対処するのが最善かを決定するのは難しい場合があるため、この件については多くの議論がありました。しかし、パフォーマンスへの影響は明らかで、多くのベンチマークで命令数が削減され、最良の場合はほぼ3%削減されました。 #160506：プロジェクトでは多くの「ロールアップ」PRを使用しており、複数のPRがまとめてマージされます。これは、CI容量が不十分で、すべてのPRを個別にマージできないためです。通常、パフォーマンスに影響するPRは個別にマージされ、その効果を明確に測定できるようにします。パフォーマンス改善PRがマージキューにこれほど多く待機していたのは初めてで、Jonathan Brouwer氏は物事を進めるために10件のパフォーマンス改善PRを含むロールアップを作成しました！これは良い問題です。その後、4件のパフォーマンス改善PRを含む#162859もありました。（個々のPRをマージした後にパフォーマンスベンチマークスイートを実行して、各PRが期待通りのパフォーマンス効果を持っていたことを確認できるため、予期しない効果が入り込む心配はありません。） #162747：このPRで、ASTからHIRへの低下処理コードにいくつかのマイナーな改善を行いました。パフォーマンスに影響しないはずのクリーンアップでしたが、多数のベンチマークで命令数が削減され、最良の場合は1.5%でした。時々、運が良いことがあります。 ジョブの状況 明日からHexcatでコンパイラパフォーマンス最適化プロジェクト目標の仕事を開始します。エキサイティングです！Mara Bos氏、Predrag Gruevski氏、そしてこれを実現するために協力してくれた他のすべての人々に心から感謝します。 編集者追記 新しいsolverの名前はPenelope Hammertimeではありません。それはジョークでした。 著者追記 その本当の名前はPineapple Häagen-Dazsです。