プロファイリングと性能分析
これは何か
プロファイリングは、プログラムの実行時間、CPU/GPU使用率、メモリ使用量、通信時間、I/O待ち時間を計測する作業です。 最適化の前に必ず行い、「どこが遅いのか」を事実で確認します。
コンテストで上位を狙うには、最初からコードや設定を勘で変えるのではなく、まず性能探偵として遅い場所を特定することが重要です。
なぜ重要か
HPCやAI推論では、遅く見える原因が一つとは限りません。
- CPU計算が重い。
- GPUが十分に使えていない。
- GPU間通信が詰まっている。
- MPI通信待ちが長い。
- KV cacheやメモリアクセスが帯域不足になっている。
- I/Oやモデルロードで待っている。
- CPU側の前処理がGPUを待たせている。
ボトルネックを特定しないまま最適化すると、スコアに効かない場所へ時間を使う危険があります。
キャッチアップすべき技術一覧
| 技術 | What | Why | When | Where | How | 重要度 |
|---|---|---|---|---|---|---|
| プロファイリング | 実行時間やリソース使用状況を計測 | 改善箇所を特定するため | 最初に必ず実施 | CPU、GPU、メモリ、通信、I/O | perf、VTune、nsys、htop、nvidia-smi | ★★★★★ |
| ボトルネック分析 | 最も遅い部分を特定 | 効果の大きい改善を行うため | プロファイリング後 | システム全体 | 時間割合分析、待ち時間分析 | ★★★★★ |
| CPU最適化 | CPU計算を高速化 | CPUが律速の場合に有効 | CPU使用率が高い時 | HPC計算、前処理 | SIMD、OpenMP、コンパイラ最適化 | ★★★★☆ |
| GPU最適化 | GPU利用率を上げる | GPUの遊び時間を減らす | GPU utilizationが低い時 | AI推論、学習 | batch調整、kernel融合 | ★★★★☆ |
| メモリ最適化 | メモリアクセスを改善 | メモリ待ちを減らす | cache missや帯域待ちが多い時 | LLM、科学計算 | cache活用、データ配置改善 | ★★★★☆ |
| MPI通信最適化 | ノード間通信を減らす | HPCでは通信が支配的になりやすい | MPI_Waitなどが長い時 | CPUクラスタ | 通信回数削減、通信隠蔽 | ★★★★★ |
| NCCL通信最適化 | GPU間通信を高速化 | マルチGPU効率を上げる | AllReduceなどが長い時 | 分散推論、分散学習 | topology確認、通信設定確認 | ★★★★★ |
| NUMA最適化 | CPUとメモリ配置を最適化 | リモートメモリアクセスを減らす | マルチソケット環境 | 大型CPUサーバ | numactl、CPU pinning | ★★★☆☆ |
| I/O最適化 | データ読み書きを高速化 | ストレージ待ちを減らす | 大量データ利用時 | 学習、シミュレーション | cache、並列I/O、出力頻度調整 | ★★★☆☆ |
| スケーリング分析 | 並列効率を測る | ノードやGPUを増やす価値を判断する | 最適化評価時 | 分散システム全般 | 1→2→4→8台比較 | ★★★★★ |
HPCコンテストでの優先順位
| 順位 | 技術 | 理由 |
|---|---|---|
| 1 | プロファイリング | 何が遅いか分からないと改善できない |
| 2 | ボトルネック分析 | 最も効果の大きい箇所を見つける |
| 3 | MPI/NCCL通信解析 | HPC・AIともに通信が律速になりやすい |
| 4 | スケーリング分析 | ノード数やGPU数を増やす価値を判断できる |
| 5 | メモリ最適化 | 現代CPU/GPUは計算よりメモリ待ちが効くことが多い |
| 6 | CPU/GPU最適化 | ボトルネックが計算だった場合に有効 |
| 7 | NUMA/I/O最適化 | 特定環境で大きな効果を発揮する |
去年の課題との対応
| 部門 | 最重要技術 | 次点 |
|---|---|---|
| NWChem(4 CPU nodes) | MPI通信解析 | スケーリング分析、NUMA最適化 |
| SGLang + DeepSeek-R1(16 H100 GPUs) | NCCL通信解析 | GPUプロファイリング、KV cache解析 |
2025年AI部門では、単純なCUDA最適化よりも、次の順番で状況を切り分ける力が重要だった可能性があります。
- GPUは本当に忙しいのか。
- GPU間通信で詰まっていないか。
- KV cache参照で帯域不足になっていないか。
- CPUがGPUを待たせていないか。
これは要確認の推測ですが、SGLangや大規模LLM推論では、GPU kernel単体の高速化だけでなく、batching、KV cache、GPU間通信、CPU側スケジューリングが全体性能に影響します。
最初に見るべき指標
| 対象 | 指標 | 見る理由 |
|---|---|---|
| CPU | CPU使用率、hotspot関数、cache miss、context switch | CPU計算や前処理が律速か見る |
| GPU | GPU utilization、SM使用率、memory bandwidth、kernel timeline | GPUが計算で忙しいか、待っているかを見る |
| メモリ | 使用量、帯域、cache miss、page fault | メモリ待ちや容量不足を見る |
| MPI | MPI_Wait、通信時間、rank間の負荷差 | ノード間通信やload imbalanceを見る |
| NCCL | AllReduce/AllGather時間、GPU間転送、topology | マルチGPU通信の詰まりを見る |
| I/O | 読み書き時間、ファイル数、ログ量 | ストレージ待ちを見る |
| scaling | 1/2/4/8ノード比較、parallel efficiency | 並列化が効いているか見る |
代表ツール
| ツール | 主な対象 | 用途 |
|---|---|---|
perf | Linux CPU | CPU hotspot、命令、cache missなどの確認 |
| Intel VTune Profiler | CPU、thread、memory、MPIなど | CPUボトルネックの詳細分析 |
NVIDIA Nsight Systems (nsys) | CPU/GPU全体timeline | CUDA kernel、CPU待ち、GPU待ち、通信の流れを見る |
nvidia-smi | NVIDIA GPU | GPU使用率、メモリ使用量、電力、プロセス確認 |
htop | CPUプロセス | CPU core使用状況、プロセス監視 |
| MPI profiling interface / PMPI | MPI通信 | MPI関数ごとの時間や呼び出しを測る |
| NCCL logs / Nsight | GPU間通信 | collective通信の時間やtopology問題を調べる |
実験の進め方
- 何も変更しないbaselineを測る。
- CPU、GPU、通信、I/Oのどこで時間を使っているかを大まかに分ける。
- 最も時間割合が大きい箇所を1つ選ぶ。
- その箇所に対して1つだけ変更する。
- 同じ条件で再測定する。
- 速くなった理由、遅くなった理由、変わらなかった理由を記録する。
実験ログテンプレート
experiment_id:
date:
target:
baseline_command:
changed_setting:
nodes:
cpus:
gpus:
input_size:
profiling_tool:
wall_time:
cpu_summary:
gpu_summary:
memory_summary:
communication_summary:
io_summary:
bottleneck_hypothesis:
result:
next_action: