Rustのパフォーマンスは実戦でどこまで通用するのか？最新の徹底検証結果を公開

Rustは「圧倒的なパフォーマンス」と「ゼロコスト抽象化」を掲げていますが、実際の現場ではどうなのでしょうか？先日開催されたC++Russia 2026にて、Zack Akimovと共にその実態を徹底調査し、登壇発表を行いました。私たちはRustのパフォーマンスにおけるトレードオフと、現在のコンパイラがそれらをどの程度最適化できているのかについて、体系的なレビューを行いました。既存資料の精査、コンパイラの解析・修正、そして膨大なパフォーマンスデータの収集を経て、現時点で最も包括的な分析結果に仕上がったと自負しています。150枚を超えるスライドには講演の核心部分をまとめており、調査過程で得られた追加データや詳細な資料はGitHubリポジトリ（ https://github.com/yugr/rust-slides/ ）で公開しています。今後のRustパフォーマンスに関する議論の土台になれば幸いです。フィードバックやご意見は大歓迎ですので、ぜひお寄せください。

やあ、みんな。スレチな質問で申し訳ないんだけど、このトークの録画って公開されてる？

すごくいい調査だね、シェアしてくれてありがとう！C/C++の世界から来た身としては、パフォーマンスに影響する微妙な違いを知れるのは最高に興味深いよ。

素晴らしい内容！Rustの追加チェックによる実際のコストがわかってよかった。数パーセントっていうのは大きい気もするけど、同時にそれだけの価値はあるってことだね。

まだスライドをじっくり読んでないからブックマークしたよ。「ゼロコスト抽象化」って響きはいいけど、実際にいじり始めると「どの抽象化が？」「どうコンパイルされて？」「どのターゲットに対して？」って話になるからね。掲示板でなんとなく噂話するんじゃなくて、実際に体系的な調査をしてくれたことに感謝するよ。今週、リカバリーライドで足が死んでて脳が暇な時に読むつもり。

うわ、めちゃくちゃ深い研究だね！タイトルが地味すぎて、内容の凄さが伝わりきってないのがもったいない。

スライド44はさらなる最適化の余地がありそうだよ：

foo:
    cmp rdx, rsi
    jae .LBB0_2
    mov eax, dword ptr [rdi + 4*rdx]
    ret
.LBB0_2:
    push rax
    lea rax, [rip + .Lanon.1]
    ...
    call qword ptr [rip + panic_bounds_check]

C++で同じことをすると.foo.coldラベルが付くから、関数の「失敗パス」セクションがライブラリのコールドセクションに移動されて、i-cacheを圧迫しないはずなんだよね。

たぶんGCCとLLVMの違いだろうけど、気にはなる :/

スライド79（シンボルのローカライゼーション）：うわ、これほどパフォーマンスに影響するとは意識したことがなかったよ。

スライド120（包含範囲の問題）：これって新しい方式の包含範囲 で解決済みかな？次のエディションで入るといいんだけど。

Rustは重要な場面でC++よりわずかに遅いし、tokioやasyncは悪夢というか信じられないほど遅い。「ゼロコスト抽象化」なんてのは、ベンチマークで突っ込んで掘り下げてみると、ある側面では看板倒れだよ。ただ、公正に評価するなら、C++と（現実的な環境で）ベンチマーク比較すれば、40個中33個くらいはRustが負けるんじゃないかな…。stdioの処理は少なくとも良いけどね。でも本当に狂ってるのは、コンテンションの壁（ソフトウェアにおいて極めて重要）さえ解決できていないことだよ。まあ、すべてを「unsafe」に書き換えればボトルネックを回避できるかもしれないけど、それだと結局、余計な手間をかけたC言語を書いてるだけで、結局言語の檻と戦う羽目になる。

信じられないのは、これほど多くのボトルネックを抱えているのに、Rustがまるで言語の最終形態だと決めつけている人が多いことだ。私にとって一番引っかかるのは、C++から30年も経って作られたものが、こんなにも持ち上げられているという現実だよ。70年代にBやCを生み出していた人たちと比べて、今のテクノロジーを使ってこれかと思うと、正直呆れる。

まあ、@kain が言及している新しい何かが登場すれば、すぐに追い抜かれるだろうけどね。

低評価は下にどうぞ👇

GPT 5.5によるスライドの要約だよ：

https://github.com/yugr/rust-slides/ は、Rustの「現実世界でのパフォーマンス特性」を、特にC/C++と比較して徹底的に掘り下げたレポジトリだ。

ライブラリやアプリというよりは、研究やトークの素材集に近く、以下が含まれている：

• 150枚以上のスライド
• ベンチマークデータ
• コンパイラの実験
• LLVMの調査
• ランタイムチェックの分析
• コンパイラパッチの概念実証
• 研究、Issue、事例へのリンク

核心的なテーマ

Rustの「ゼロコスト抽象化」は「概ね正しい」が、魔法のようにタダというわけではない。

Rustは多くの場合、C/C++に近いパフォーマンスを叩き出すけれど、特定の状況では測定可能なオーバーヘッドが発生する：

• 安全性チェック
• パニック処理の仕組み
• 初期化ルール
• イテレータの抽象化
• 境界チェック
• エイリアシングルール
• シンボルの可視性
• LLVMパイプラインの挙動

このレポジトリでは、そうしたオーバーヘッドがどこに存在し、最適化後にどこで消失するのかを定量化しようとしている。

大きな収穫

1. Rustは全体的に非常に高速

このレポジトリは「反Rust」ではない。
大まかな結論は：

Rustは通常、最適化されたC++と非常に近い性能を発揮する。

特に以下の条件で顕著だ：

• 成熟した最適化済みのコードベース
• CPU負荷の高いタスク
• LLVMがインライン展開やチェックの排除を行えるコード

2. 安全性はタダではないが、思ったより安い

レポジトリでは以下を詳細に検討している：

• 境界チェック、オーバーフローチェック、パニックのパス、強制初期化、ランタイムアサーション

結論としては：

• 多くのチェックは最適化で消える
• どうしても消えないものもある
• 残ったコストも許容範囲内であることが多い

また、現代のハードニングされたC++アプローチとも比較しており、ランタイムの挙動としては両者が収束しつつあるが、総合的な保証は依然としてRustの方が強力だと論じている。

3. LLVMの挙動が非常に重要

興味深いテーマの一つは、パフォーマンスの話は「Rust対C++」というより、「どのLLVMパスが走ったか」という議論になりがちな点だ。

• コールドスプリッティングは行われたか？
• シンボルのローカライズは起きたか？
• 境界チェックは畳み込まれたか？
• パニックのパスは分離されたか？
• インライン展開は適切なタイミングで行われたか？

著者たちはこれらの影響を調査するために、独自のコンパイラパッチや実験を行っている。

4. Rustの人間工学がピークパフォーマンスと競合することがある

Rustの設計が、時として以下のような方向へ誘導してしまうケースにも触れている：

• 余分な初期化
• 不自然な自己参照構造体
• イテレータの複雑さ
• 隠れたパニックパス
• 余分な分岐

これらは致命的ではないが、注意が必要だ。

• 包括的な範囲指定の癖
• MaybeUninitの境界ケース
• 境界チェックの下げ
• コールドパスの配置
• パニックによる命令キャッシュの汚染
  などが例として挙げられている。

5. 非常に包括的なレポジトリ

単に「Rust速いぜ」という話じゃない。

• ベンチマークハーネス、コンパイラの計測、LLVMのIssueへのリンク、Godboltの例、アセンブリ分析、証明リンク、コンパイラパッチ、マイクロベンチマーク、ランタイムチェックの切り替えスイッチなどが含まれている。

要するに：

Rustのパフォーマンスを大学院レベルで徹底的にフォレンジック調査したらどうなるか？

要約（TL;DR）

一言でまとめると：

• Rustのパフォーマンスは通常素晴らしく、C++に近い。
• 安全性機能にはコストがあるが、多くは最適化で消える。
• 構造上避けられないコストもある。
• LLVMの最適化品質が結果を大きく左右する。
• パニックやランタイムチェックのコード生成は意外と重要。
• 「ゼロコスト抽象化」は方向性としては正しいが、文字通り無料ではない。
• 思想論ではなく「どこでコストが発生するか」をカタログ化した価値ある資料。

全体的な雰囲気：

Rustはマーケティングのスローガンではなく、真剣なエンジニアリングの精査に値する。

これは最高だね、ありがとう🤩🙏 トークの録画は公開されてる？

やあ、全部読み込めたわけじゃないけど、多くの比較で抜け落ちがちな「本質的なギャップ」を初期段階で指摘してくれてありがとう。本当に重要なのは、慣用的なコードを書いた時の差だよね。ベンチマークだとコンパイラの性能を測るためにあえて特殊なコードを使うことが多いけど、指摘の通り、ほとんどのケースでは似たようなものだし、重要なのは言語設計そのものだ。それに、あまりに特殊なコードなら、そもそも人が書こうとも思わないものだし、unsafeかどうかさえどうでもよくなるよね。