# Instructions Per Cycle(IPC) > [!note] 名称の混同に注意 > このページの **IPC = "Instructions Per Cycle"**(サイクルあたり命令数)はコンピュータアーキテクチャの指標である。wiki 内の [[IPCメトリクス]] は "Inter-Process Communication Metrics"(プロセス間通信メトリクス)であり、全く異なる概念。 ## 定義 IPC(Instructions Per Cycle)とは、CPU が 1 クロックサイクルあたりに平均何命令を実行(retire)できるかを示すハードウェア性能指標である。ハードウェアカウンタの `instructions` / `cycles` として計測される。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]]) ### IPC による診断基準 | IPC 値 | ボトルネック種別 | 意味 | 対処 | |--------|--------------|------|------| | **< 1.0** | メモリバウンド | CPU がメモリ待機(ストール)に多くのサイクルを消費 | メモリ I/O 削減・キャッシュ改善・データ局所性最適化・プリフェッチ | | **≥ 1.0** | 命令バウンド | CPU はほぼフル稼働。命令数が多い | アルゴリズム改善・命令数削減・SIMD 最適化 | 4-wide 設計(理論最大 IPC = 4)のプロセッサで IPC = 0.78 なら最高速度の 19.5% しか利用できていない。 ### Linux での計測方法 ```bash # システム全体(10 秒間) perf stat -a sleep 10 # プロセス単位 perf stat -e cycles,instructions,stalled-cycles-frontend,stalled-cycles-backend -p <PID> ``` `perf stat` の出力には `insns per cycle` として IPC が直接表示される。 ## なぜ %CPU ではなく IPC が重要か [[CPU利用率]](%CPU)は「非アイドル時間」を測るが、CPU が演算中かメモリ待機中かを区別しない。IPC はこの曖昧さを解消し、CPU が実際にどれだけの仕事をしているかを示す。Gregg(2017)は IPC こそが %CPU の正しい補完指標と主張する。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]]) ## 横断的知見 - **IPC はハードウェアカウンタで直接計測できる**: CPU 内蔵の PMC(Performance Monitoring Counter)が `cycles` と `instructions` を計数し、Linux `perf`・Intel VTune・AMD μProf 等のツールが IPC を計算・報告する。[[ハードウェアカウンタ]] ページの先行知見(演算子別 PMC による stall 定量化)は IPC 解釈と一致する。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]], [[@2026__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) ## 未解決の問い - ヘテロジニアスアーキテクチャ(big.LITTLE、P/E コア混在)では IPC をどのコア基準で正規化すべきか。 - マルチスレッド/SMT 環境では IPC がスレッド間でどう干渉するか。 - GPU における IPC の類比は何か(SIMD スループット、ワープ効率、メモリ帯域利用率など)。 ## 関連 - ソース: [[@2017__brendangregg.com__CPU Utilization is Wrong]] - 概念: [[CPU利用率]] / [[ハードウェアカウンタ]] / [[メモリバウンド]] / [[継続的プロファイリング]] - エンティティ: [[Brendan Gregg]] - 別概念(混同注意): [[IPCメトリクス]](Inter-Process Communication Metrics) ## 出典 - [[@2017__brendangregg.com__CPU Utilization is Wrong]]（IPC の診断基準・Linux perf による計測法・%CPU との対比）