PGO の仕組みと効果的な運用手法

本稿は、PGO（Profile-Guided Optimization）の仕組みを解説します。内容の複雑さを考慮し、以下の 3 つのポイントに分けて整理しました。

1. PGO とは何か
2. PGO がどのように動作するか
3. sysbench でのトレーニングが失敗する理由と正しいやり方

PGO の仕組み

PGO は、コンパイルプロセスを「二段階ビルド」で実行する技術です。

• 第 1 パス：プロファイル収集（インストルメント化）

  • -fprofile-generate

    オプションを指定してコンパイルします。
  • この段階では、基本ブロックや分岐命令ごとにカウンターが用意されます。
  • トレーニング用ワークロードを実行し、各パスの実行数をカウンターで記録します。
  • 収集されたデータは、

    profraw

    というファイルとしてダンプ（保存）されます。

• 第 2 パス：最適化コンパイル

  • 第 1 パスで収集したカウンターデータを基に再コンパイルを行います。
  • これにより以下の最適化が適用されます。
    • インライン化の判断: どの関数をどこまで展開するかを決定します。
    • 分岐命令の配置: 「熱いパス」は直進させ、「冷たいパス」はジャンプさせるように物理的に移動させます（

      .text.unlikely

      セクションへの配置など）。
    • ホット/コールド関数の分割: 1 つの関数内に「熱いコア」と「稀なエラー処理」があった場合、コードを物理的に分割します。
    • コード順序の整理: 指令キャッシュや iTLB の局所性を高めるため、呼び出し順に再配置します。
    • ループアンロール（ループ展開）: 最適化の度合いを変化させます。
    • 間接コールの促進: 仮想関数テーブルなどの最適化を行います。

PGO の本質的な目的

重要: PGO の目的は、「トレーニングしたワークロードだけを高速にする」ことではありません。

• コンパイラに「どのコードが熱い（よく実行される）か」「どのコードが冷たいか」を知らせます。
• その情報に基づき、バイナリ全体のリシェイプ（物理的な再配置） を行います。

具体的にどのように機能するか

フェーズ 1：記録されている情報の粒度

インストルメント化されたバイナリには、関数単位の情報は含まれません。以下のような詳細な情報が記録されています。

• エッジ単位の記録: すべての分岐命令、ループのバックエッジ、すべてのコールサイトに対して「パスの実行数」を記録します。
  • 例：

    if (A) { } else { }

    において、「左へ 95 万回、右へ 50 回」といった詳細なデータが取得されます。
• メリット: 「関数 X は熱い」という粗粒な分類を超え、エッジごとの粒度で外科的かつ精密な最適化判断が可能です。

フェーズ 2：カウンターデータの活用方法（トランスフォーム）

収集したデータに基づき、コンパイラは以下の処理を実行します。

1. インライン化 (Inlining)

• 通常: 関数のサイズやコールサイトの数などの静的なヒューリスティックに基づいて判断します。
• PGO での変更: プロファイルデータを優先し、静的評価と異なる決定を行います。
  • 「高価そうだが」実際には頻繁に呼び出されるコード: 数百万回実行された場合は、ランタイムの便益がコードサイズ増によるコストを上回るため、インライン化されます。
  • 「可能だが」冷たいパスにあるコール: デッド・コード領域にある場合、インライン化してもバイナリを肥大化するだけの無駄になるため、インライン化は行われず通常のコール命令として残されます。

2. 分岐命令の配置 (Branch Layout)

• 基本原理:

  if

  文はコンパイル時に「直進（Fall-through）」か「ジャンプ」かのいずれかに変換されます。
  • 直進: CPU が次の指令を読み取る準備ができており、追加コストなし（無料）。
  • ジャンプ: パイプラインバブルが発生し、予測ミスがあればペナルティが発生します。
• 最適化戦略:
  • 熱いパス $\rightarrow$ 「直進」させるように配置します。
  • 冷たいパス $\rightarrow$ 「線から外す（Push out）」ように物理的に移動させます（例：

    .text.unlikely

    セクションへ）。
• 注意点: ソースコード内の

  if/else

  の順序を入れ替えても、コンパイラはプロファイルデータに基づいて配置を決定するため、ソース順序の変更だけでは効果はありません。

3. ホット/コールド関数の分割 (Hot/Cold Function Splitting)

• 仕組み: 1 つの関数内に「熱いコア」と「稀な処理」があれば、物理的に 2 つの部分に分割します。
  • 熱い部分:

    .text.hot

    セクションに保持（高密度化）。
  • 冷たい部分:

    .text.unlikely

    セクションへ移動。
• 効果: 熱い部分が指令キャッシュラインに収まりやすく、冷たいコードが熱いコードのキャッシュスペースを奪うのを防ぎます。

4. バイナリ全体の関数再順序化 (Whole-binary function reordering)

• 仕組み: リンク時（特に LTO 有効時）に関数の配置を物理的に再調整します。
  • 呼び出し合う頻度の高い関数を、メモリ上で近接するように配置します。

  • mysqld

    のような巨大なバイナリにおいて、CPU が「熱い関数の密なクラスター」を読み込むように誘導します。
• 効果: 指令キャッシュと iTLB の局所性が最大化されます。通常のビルドではコンパイル順序どおりの配置になるため、ランタイムのコールパターンと不一致になりがちですが、PGO で是正されます。

5. 間接コールの促進 (Indirect-call promotion)

• 対象: 特定のターゲットに解決する頻度が圧倒的に高い場合（例：C++ の虚関数テーブル）。
• 処理: 「ガード付きの直接コール」を挿入します。
  • 例：

    if (target == specific_address) { direct_call() } else { indirect_jump() }

• 効果: テーブル経由のジャンプよりもコストが安く、分岐予測器への負荷が減ります。

6. レジスタ割り当てとコード密度のトレードオフ

• 熱いコード: 速度を優先。積極的なループ展開や、値に割当てるレジスタ数の増加などを実行します。
• 冷たいコード: サイズを優先（フットプリント削減）。レジスタ数を減らし、ループ展開を抑制します。
• 理由: 冷たいコードはディスクやページキャッシュスペースを無意味に占有するのを防ぐため、

  .text.unlikely

  へ隔離されます。

7. スイッチ文・ジャンプテーブルの低次化 (Switch/jump-table lowering)

• 仕組み:

  switch

  文には「ジャンプテーブル（高速だが全ロードが必要）」と「比較カスケード（低速だが特定ケースに強い）」の 2 つのアプローチがあります。
• PGO の判断: プロファイルデータが示す「実際の運用で支配的なケース」に基づいて、最適なアプローチを選択します。

PGO と MTR (Multi-Threaded Replay) の関係性

• 重要ポイント: トレーニング中の処理値が本番と完全一致する必要はありません。「制御フローの形状」 が合っていれば十分です。
• MTR の利点: 実際のクエリやデータとは異なる TPCC ワークロードであっても、

  mysqld

  のほぼ全てのコードパスをウォークするため、「制御フローの形状」という観点では合致します。このため、PGO の効果が広く異なるデータセットにも転移します。

なぜ sysbench でトレーニングしたビルドが負けてしまうのか、そして正しいやり方

sysbench などの合成ワークロードのみで PGO を行うと、以下の理由でパフォーマンス向上が得られない場合があります。

• 制御フローの偏り: sysbench のみを実行すると、「熱いパス」の特定が不正確になり、実際の複雑な本番ワークロードとは異なる最適化バイナリが生成されてしまいます。
• 解決策: PGO を行う際は、MTR などの多様なコードパスをカバーするトレーニングデータを使用する必要があります。これにより、制御フローの形状が正しく把握され、バイナリの再配置が適切に行われます。

結論: トレーニングワークロードの単一性に頼らず、可能な限り多様なシナリオで PGO 訓練を行うことが重要です。