Ryzen Zen 5がGCCの2行修正で最大12％高速化｜対象は特定ベンチのみ、ゲームFPSは変わらず【2026年8月】

出典：Phoronix「GCC Patch Adjusting AMD Zen 5 Misprediction Cost Nets 12% Win In Benchmark」、GCC開発者向けメーリングリスト「gcc-patches」2026年8月投稿分（Venkataramanan Kumar氏のパッチ本文）、Phoronix「One Line x86 Change To GCC Compiler Nets +12% Benchmark Win For Modern Intel/AMD CPUs」、GCC公式Gitリポジトリのコミット履歴（Lili Cui氏、2026年6月24日）、SPEC公式「544.nab_r」ベンチマーク説明、Tom’s Hardware「AMD Announces Zen 5 and Ryzen 9000 Processors」にもとづきます。本記事の情報は2026年8月24日時点のものです。

「GCCのわずか2行の修正でCPU性能が12％向上」という見出しだけを見ると、Ryzenを使っているユーザー全員に関係する大きなアップデートのように感じるかもしれません。ですが実際に何が変わり、どこまでのユーザーに影響するのかは、パッチの中身を確認しないと判断できません。

今回の変更は、AMDのコンパイラエンジニアが2026年8月22日にGCCの開発者向けメーリングリストへ投稿したもので、Zen 4・Zen 5向けの内部設定ファイルにある「分岐予測が外れたときのコスト見積もり」を引き上げる内容です。SPEC CPU 2017に含まれる「544.nab_r」というベンチマークで、Zen 5は約12％、Zen 4は約9％の性能向上が確認されていますが、この数値が指すのは特定の最適化オプションでコンパイルした1つのベンチマークの結果です。

この記事では、AMDが投稿した実際のパッチの中身、分岐予測コストというGCC内部の仕組み、先行して既にGCCへ取り込まれているIntel側の同種の変更、そして市販のPCゲームやLinux・Proton環境への影響まで、GCCメーリングリストとPhoronixの報道にもとづいて整理します。

要点まず何が起きたか

経緯AMDのエンジニアが2026年8月22日にGCCへパッチを投稿

AMDのコンパイラエンジニアであるVenkataramanan Kumar氏は、2026年8月22日、GNUコンパイラコレクション（GCC）の開発者向けメーリングリスト「gcc-patches」へ、件名「[PATCH] x86: Increase znver4/5 tune branch misprediction cost」というパッチを投稿しました。GCCはLinuxディストリビューションをはじめ幅広い環境で使われるオープンソースのコンパイラで、AMDやIntelといったCPUメーカー自身も、自社CPU向けの最適化パラメータを継続的に提案・修正しています。今回のパッチもその一環で、Zen 4・Zen 5世代のCPU向けに用意されている内部設定を調整する内容です。

Kumar氏はパッチ本文で「x86_64-linux環境でブートストラップとテストを行った」としたうえで、GCCのメンテナーへ「Ok for staging?」（次期開発版へ取り込んでよいか）とレビューを依頼しています。2026年8月24日時点で、このパッチはまだGCCの開発版（Git）へ取り込まれておらず、レビュー待ちの段階です。

中身変更されるのはznver4とznver5のわずか2行

変更対象は、GCCのソースコード内にある「x86-tune-costs.h」というファイルです。このファイルには、CPUの世代ごとに「どの処理にどれくらいのコストがかかるか」をGCCへ伝えるための数値テーブルが並んでおり、Zen 4向けの「znver4_cost」、Zen 5向けの「znver5_cost」もこの中にあります。今回のパッチは、両方のテーブルにある「Branch mispredict scale」という項目を、それぞれ次のように書き換えるものです。

znver4_cost・znver5_cost共通の変更点（GCC公式パッチより）

-  COSTS_N_INSNS (2),          /* Branch mispredict scale.  */
+  COSTS_N_INSNS (2) + 3,      /* Branch mispredict scale.  */

変更されるのはznver4_costの1行とznver5_costの1行、合計2行だけです。GCC公式のパッチには「1 file changed, 2 insertions(+), 2 deletions(-)」と記録されており、規模としては極めて小さい修正です。「COSTS_N_INSNS」はGCC内部で「命令何個分のコストか」を表すマクロで、この数値が大きいほど、GCCはその処理を重いものとして扱い、コード生成の判断を変えます。今回の変更は、CPUのマイクロコードや実際の分岐予測アルゴリズムそのものを書き換えるものではなく、GCCが「分岐予測が外れたときのペナルティをどれくらい重く見積もるか」というコンパイラ側の判断基準を引き上げるものです。

AMDのパッチ本文には、この数値を引き上げる技術的な理由についての説明はありません。一方、後述する先行事例であるIntel側のコミットメッセージには、「現代のCPUはパイプラインが深くなっており、分岐予測が外れた場合のコストがより大きくなっている。このコストを引き上げることでGCCはif文を条件分岐ではなく別の命令列に変換する『if変換』を選びやすくなり、分岐予測ミスによるパイプラインの停止を避けられる」という趣旨の説明が添えられています。

検証結果SPEC CPU 2017の544.nab_rで確認された数値

AMDのパッチ本文によると、今回の変更によってSPEC CPU 2017に含まれる「544.nab_r」というベンチマークが、「-O3 -march=native -flto」という最適化オプション付きでコンパイルした場合、Zen 5で約12％、Zen 4で約9％向上したとしています（single-copy、つまり1コピーのみを実行する条件での結果です）。SPEC CPU 2017は業界標準として広く使われるCPU性能測定用ベンチマーク集で、544.nab_rはそのうちの1つです。

SPEC公式の説明によると、544.nab_rは「Nucleic Acid Builder（NAB）」という核酸分子モデリングソフトウェアをもとにしたベンチマークで、生命科学計算でよく使われる浮動小数点演算を集中的に行うプログラムです。ANSI C言語で書かれており、PDB形式（原子座標）・PRM形式（力場）のテキストファイルを入力として、分子動力学シミュレーションを実行します。ゲームのグラフィックス処理や物理演算とは性質の異なる、分岐の多い数値計算プログラムです。パッチ本文でも「このベンチマーク以外のワークロードにも恩恵がある可能性は高いが、コンパイラのチューニング検証には慣例的にSPEC CPUが使われる」という趣旨の説明にとどまっており、SPEC CPU以外のベンチマークでの効果は示されていません。

先行事例Intel側の同種パッチはすでにGCCへ統合済み

実は「分岐予測コストの引き上げ」という同じ手法は、AMDより先にIntelのエンジニアLili Cui氏が試みています。Cui氏は2026年6月24日、GCCの「generic」チューニング（特定のCPU世代を指定せずビルドする場合に使われる汎用設定）について、branch misprediction scaleを同じく「COSTS_N_INSNS (2)」から「COSTS_N_INSNS (2) + 3」へ引き上げるパッチをGCCへコミットしました。コミットメッセージでは、「-O2」でコンパイルした544.nab_rが、Intelの「Granite Rapids」で12.7％、AMD Zen 5で12.1％向上したと報告されています。

このgenericチューニング向けパッチは既にGCCの開発版へ統合済みで、来年公開予定のGCC 17に含まれる見込みです。つまり、Zen 4・Zen 5に特化した数値の調整は今回のAMDパッチ（まだレビュー中）で行われるものですが、CPU世代を指定しない汎用ビルドについては、Intelのエンジニアが提案した同種の調整がすでに一足先に取り込まれていることになります。AMDとIntelという異なる企業のエンジニアが、それぞれ独立に同じ結論へたどり着いた点は興味深いところです。

対象Zen 4はRyzen 7000/8000、Zen 5はRyzen 9000とX3Dが該当

今回話題になっているのは、GCCで「-march=znver4」または「-march=znver5」を指定してコンパイルした場合、あるいは該当CPU上で「-march=native」を使ってコンパイルした場合に適用される設定です。AMD公式によれば、Zen 4アーキテクチャはデスクトップ向けRyzen 7000シリーズおよびRyzen 8000シリーズの一部（8000Gなど）に、Zen 5アーキテクチャはRyzen 9000シリーズに採用されています。

Ryzen 7 9800X3DのようなX3Dモデルも、コア自体はZen 5アーキテクチャであるため、GCCの分類上は同じznver5_costテーブルの対象です。ただし今回変更されるのはあくまで分岐予測コストの見積もりであり、X3Dモデルの特徴である3D V-Cache（垂直方向に積層された追加のL3キャッシュ）の動作そのものとは別の仕組みです。3D V-Cacheの有無によってこの変更の効果が変わるかどうかについて、AMD・Intelいずれのパッチにも言及はありません。

実利用市販ゲームのFPSが今すぐ変わるわけではない

ここまでの内容を踏まえると重要なのは、今回の変更が「Ryzen自体が12％速くなるアップデート」ではないという点です。示されているのはSPEC CPU 2017に含まれる544.nab_rという1つのベンチマークについて、特定の最適化オプションでコンパイルした場合の結果であり、PCゲームのフレームレートを対象にした計測ではありません。

市販されているPCゲームの多くは、Steamなどのプラットフォームで配布される時点で、開発元がすでにコンパイルを終えた実行ファイルの形になっています。ユーザー側のPCでGCCの設定を変えたり、GCCを更新したりしても、すでに配布されているゲームの実行ファイルの中身が書き換わるわけではありません。したがって、このパッチが将来GCCへ取り込まれたとしても、それだけで手持ちのゲームのFPSが自動的に変わることはありません。仮に何らかの形で恩恵を受けるとすれば、GCCで自分でビルドしたソフトウェアや、開発元が今後新しいバージョンのGCCで再ビルドした場合に限られます。

LinuxProtonはWindows向け実行ファイルをそのまま動かす仕組み

GCCはLinux環境で広く使われるコンパイラであるため、「Linux版のゲームには影響があるのでは」と考える人もいるかもしれません。ただしSteamの互換レイヤー「Proton」は、Windows向けにビルド済みの実行ファイルをSteamOS・Linux上でそのまま動かす仕組みであり、Proton自体がゲーム本体のコードをGCCで再コンパイルするわけではありません。そのため、今回のGCCパッチが取り込まれたからといって、Proton経由で遊んでいるWindows向けゲームのコードが自動的に最適化されるわけでもありません。

Proton・Wine自体が将来新しいGCCでビルドされた場合に、互換レイヤー部分の処理に何らかの影響が及ぶ可能性は考えられますが、そうした効果を示す実測データは現時点で公表されていません。

今後GCC 17への搭載見込みとGCC 16.3バックポートの可能性

AMDのKumar氏によるZen 4・Zen 5専用のパッチは、2026年8月22日時点でGCCメーリングリストへ投稿されたばかりで、正式に採用されるかどうかはメンテナーによるレビュー結果次第です。Phoronixの報道では、パッチ自体の規模が小さいこともあり、大きな問題が見つからなければ、次期メジャーバージョンであるGCC 17の開発版へ取り込まれる可能性が高いとされています。すでにリリースされているGCC 16系列の保守バージョンであるGCC 16.3へ、この変更が遡って適用（バックポート）される可能性も指摘されていますが、2026年8月24日時点でこれは確定した情報ではありません。

Phoronixは同記事で、AMDが新しいCPU向けの目標をGCCやLLVM/Clangへ以前より早い段階でアップストリーム化するようになった一方、こうした細かなコストテーブルの調整は発売から数カ月遅れて行われることが多く、GCCのリリースサイクルの長さもあって反映のタイミングが不利になりがちだと指摘しています。

FAQよくある質問

あわせて読みたい

CPU

AMD Zen 6「Medusa」リーク徹底解説——2GHz動作ESのIPC衝撃とAM5継続

CPU

Ryzen 7 9700X vs 7800X3D 徹底比較｜ゲーム性能・消費電力・価格でどっちを買うべきか

ニュース

Linux 7.3でGPUスケジューラ「Fair」再採用へ？RX 9070 XTの10FPS低下を2パッチで修正

トラブル・設定

シェーダーコンパイル・スタッタリング対処完全ガイド｜UE5世代のカクつきを5タイプ別に潰す