ボトルネック分析
このページは、2026-06-05の勉強会でチームが共有したボトルネック分析の基礎をまとめたものです。 担当: 渡邉。
これは何か
ボトルネック分析とは、プログラム全体の実行時間のうち、どこが最も時間を使っているかを切り分ける作業です。 最適化の前に必ず行い、「速くすべき場所」を事実で決めます。
なぜ重要か
HPCでは、「CPUが遅いからCPUを速くする」という発想は的外れになりやすいです。 実際には、次の場所がボトルネックになることが多いです。
- メモリアクセス（帯域待ち）
- ノード間通信（MPI）
- 同期待ち（待機・idle）
つまり、計算そのものより「待ち時間」が支配的になりやすい、という認識が出発点です。
基本フロー
最初に、全体時間を次の観点で分解します。
| 見るもの | 何が分かるか |
|---|---|
| 計算・通信・I/Oの時間割合 | どのカテゴリが支配的か |
| 関数・プロセス・スレッドごとの時間 | どの処理が重いか（hotspot） |
| CPU使用率 | 計算で忙しいのか、待っているのか |
| MPI通信時間 | ノード間通信が律速か |
マクロからミクロへ：最適化の定石
いきなりソースコードの行を見てはいけません。 ボトルネックの「種別」を大局から絞り込みます。
| フェーズ | 粒度 | やること | 代表ツール例 |
|---|---|---|---|
| Phase 1 | マクロ（低負荷） | CPU/GPU/メモリ/通信のどこが遅いか切り分け | Linaro MAP、Nsight Systems、perf、mpiP、IPM |
| Phase 2 | ミドル（中負荷） | 関数特定、並列インバランス・待機状態の定量化 | Score-P、TAU、HPCToolkit |
| Phase 3 | ミクロ（高負荷） | 行レベルの原因（cache miss、依存関係）解明 | Scalasca、Nsight Compute、Callgrind、ftrace |
合言葉は「推測するな、計測せよ」。低負荷ツールで「当たり」をつけ、高負荷ツールで「原因」を特定します。
ツールの詳細はプロファイリングツール実践ガイドにまとめています。
注意点
- 計測ツール自体にオーバーヘッドがあります。マクロ→ミクロの順で、必要なときだけ重いツールを使います。
- 1回の実験で変える条件は1つにします。
- 「速くなった」だけでなく、なぜ速くなったかを記録します。