コンパイラの定数を1つ書き換えただけで、ベンチマークが12%超速くなった——そんな変更がGCCに入ります。

この記事では、Intelのソフトウェアエンジニア Lili Cui氏が提案したGCCの分岐誤予測コスト調整の内容と、なぜ小さな修正で大きな差が出るのかを整理します。

この記事でわかること

  • GCCのgeneric_costで何が変わったか
  • 分岐誤予測とif-conversion（分岐なしコード化）の関係
  • 12%向上が計測された条件と、その限界
  • 変更が届くGCC 17のタイムライン

何が変わったか

2026年5月、Lili Cui氏はGCCのメーリングリストにパッチを投稿しました。変更箇所はgcc/config/i386/x86-tune-costs.hの1行だけです。

分岐誤予測のコスト係数（Branch mispredict scale）を、COSTS_N_INSNS(2)からCOSTS_N_INSNS(2) + 3へ引き上げました。ファイル全体で1行の差分、挿入1・削除1という最小限の修正です。

対象はCPU固有の-march=nativeではなく、汎用x86/x86_64チューニング（generic_cost）です。特定のマイクロアーキテクチャ向けにビルドしていないプロジェクトが、GCC 17以降で恩恵を受ける可能性があります。

なぜ分岐のコストを上げるのか

CPUは分岐（if文などの条件分岐）に遭遇すると、次に実行する命令を先読みして処理を進めます。これを投機実行と呼びます。予測が外れると、パイプラインを巻き戻す必要があり、性能を大きく失います。この巻き戻しを分岐誤予測（branch misprediction）と呼びます。

近年のIntel・AMDプロセッサはパイプラインが深くなり、誤予測のペナルティが旧世代より重くなっています。一方、GCCの汎用チューニングが想定する分岐誤予測コストは、古いマイクロアーキテクチャ基準のまま残っていた、というのがCui氏の指摘です。

コスト係数を上げると、コンパイラは「分岐をそのまま残すより、分岐なしの命令列に書き換えた方が得」と判断しやすくなります。条件付き移動（cmov）やその他の分岐なしパターンへ置き換える最適化をif-conversionと呼びます。AMDのVenkataramanan Kumar氏の整理によると、この変更で予測不能な分岐に対するif-conversionの上限コストが24から33へ上がり、比較分岐の代わりにコストの高いcmov列を選びやすくなります（参考）。

12%向上が出たベンチマーク

計測はSPEC CPU 2017の544.nab_r（Nucleic Acid Builder）で行われました。分子の物理・化学計算を行うワークロードで、分岐の挙動がスループットに効きやすいとされています。最適化レベルは-O2、single-copy構成です。

結果は次のとおりです。

  • Intel Granite Rapids（GNR）: 12.7%向上
  • AMD Zen 5（Znver5）: 12.1%向上

Phoronixの報道でも同数値が紹介されており、IntelとAMDの最新世代の双方で同程度の改善が確認されています（参考）。

数字の読み方と限界

12%は目を引く数字ですが、適用範囲は限定的です。Cui氏はgcc-patchesで、他のSPEC CPU 2017・SPEC CPU 2026ベンチマークはこのパラメータに敏感ではなかったと述べています。SPEC CPU 2026全体ではわずかな改善は見えたものの、信頼できるほどの差ではなかったとも説明しています。

+3という値は経験的に決められました。40まで引き上げてもGNR・Znver5で追加の利益はなく、最小限の調整で効果を取り切れる保守的な選択だとCui氏は回答しています。分岐が多く予測が外れやすいホットループでは恩恵が出やすく、メモリアクセス待ちが支配的なコードでは影響が小さい、という見方が妥当です。

GCC 17への取り込み

このパッチはGCCのtrunk（開発版）にマージ済みで、安定版としてはGCC 17に同梱される見込みです。GCC 17の正式リリースは2027年を想定しており、現行のGCC 16系を使っている環境では、すぐには反映されません。

AMD側もベンチマーク検証を進めており、パッチ投稿後にKumar氏が検証予定を示していました。汎用チューニングへの変更のため、ベンダー横断で広く効く設計になっています。

開発者にとっての示唆

新しいハードウェアが出るたびに、コンパイラ内部の「コストモデル」も更新が必要になる、というのが今回の教訓です。アプリのソースを書き換えず、ツールチェーンの定数調整だけで二桁近い改善が出るケースは稀ですが、存在します。

一方で、今回の12%は単一ベンチマークの結果です。自分のプロジェクトが同程度の恩恵を受けるかは、分岐の多さと予測の難しさ次第です。-O2かつ汎用x86チューニングでビルドしているC/C++プロジェクトは、GCC 17リリース後に再ビルドして計測する価値があります。CPU固有オプションを既に使っている場合は、今回のgeneric_cost変更の影響は限定的になる点にも留意してください。