# 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 が直接表示される。 ### CPI(逆数表現)との使い分け IPC の逆数は CPI(cycles per instruction、命令あたりサイクル数)と呼ばれる。Linux コミュニティおよび perf(1) は IPC を使うが、Intel など一部は CPI を好む。『詳解 システム・パフォーマンス 第2版』の著者は初版で CPI を使っていたが、Linux 関連の仕事が増えるにつれ IPC に切り替えたと述べている。Netflix のクラウドワークロードの実測では IPC は 0.2(遅いとみなされる)から 1.5(良好)の範囲であり、CPI に換算すると 5.0 から 0.66 になる(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.3.7)。 ### ハードウェアレベルの計測ツール pmcarch(8)(Intel “architectural set” PMC ベース)は `K_CYCLES`・`K_INSTR`・`IPC`・分岐予測ミス率(`BMR%`)・LLC ヒット率(`LLC%`)を毎秒表示する。tlbstat(8)は同様の形式で TLB ウォークの割合(`DTLB%`・`ITLB%`)を示し、たとえば KPTI パッチの最悪条件では CPU 時間の半分が TLB ウォークに費やされ IPC が 0.10 まで低下する例が示されている(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.11, §6.6.12)。`perf stat` によるシステム全体の IPC 計測は NUMA チューニングの効果測定にも使われ、書籍の実例では IPC が 0.72 から 0.89(24%向上)に改善し、実際のスループット向上(20〜30%)と符合した(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.13.6)。 ### perf statのシャドウ統計としてのIPC(13章) `perf stat` で `cycles` と `instructions` を同時にインストルメンテーションすると、IPC がシャドウ統計(shadow statistics)として自動的に `#` 付きで表示される(例: `2,895,806,892 cycles` / `6,452,798,206 instructions # 2.23 insn per cycle`)。こうした派生統計は特定のイベントの組み合わせが指定されたときにだけ表示され、イベント引数なしの `perf stat` の出力にも複数含まれる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.8.5) ### 実務調査での適用例(16章) Netflix のマイクロサービスを VM とコンテナで比較したケーススタディでは、`pmcarch(8)` により VM の IPC が 0.57、コンテナの IPC が 1.52 と計測され、2.6倍の差がスピード差の2.6倍分を説明するとされた。この差の主因は LLC ヒット率(VM 約30%、コンテナ約90%)であり、LLC サイズの小ささ・VM 側のワークロードの複雑さ(サブコンポーネントでなく全体を実行)・CPU 飽和による高頻度コンテキストスイッチ([[コンテキストスイッチ]])という3つの要因が重なってLLCヒット率(ひいてはIPC)を押し下げていた。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.5, §16.1.8) ## なぜ %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__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **診断基準の閾値は両ソースでほぼ一致するが、書籍の方がプロセッサ依存性を明示する**: Gregg(2017)は IPC < 1.0 をメモリバウンド、≥ 1.0 を命令バウンドと単純化するが、『詳解 システム・パフォーマンス 第2版』6章は実測値(Netflix クラウドで IPC 0.2〜1.5)を示しつつ「高い/低いの基準はプロセッサによって異なり実験的に判断すべき」と釘を刺す。閾値は目安であり、既知のワークロード(メモリ集中 vs 命令集中)を実行して自環境の基準を作る必要がある。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.3.7) - **6章の実測値・13章のシャドウ統計・4章のPMC分類は、IPCが「単発の計測手順」ではなく「perf(1)の標準出力機能」であることを裏付ける**: 6章は`perf stat`によるIPC計測の実例(NUMAチューニング前後で0.72→0.89)を示すが、13章はより基礎的なレベルで、IPCが`cycles`と`instructions`を同時に指定するだけで自動計算される「シャドウ統計」という`perf stat`の一般機能であることを明らかにする。つまりIPCはユーザーが式を組み立てて算出する派生指標ではなく、perf(1)が組み込みで提供する標準出力の一部であり、6章の実例はこの一般機能の適用例と位置づけ直せる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.13.6, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.8.5) - **16章の実測値(VM 0.57・コンテナ1.52)は、6章が示すNetflixクラウド全体のIPC分布(0.2〜1.5)のちょうど両端に近い値であり、同一メソドロジ・同一プロセッサ系統で計測された実例が書籍全体で一貫していることを裏付ける**: 6章はNetflixのクラウドワークロード全体でIPCが0.2(遅い)〜1.5(良好)の範囲だと述べるが、16章の個別ケースはこの分布のほぼ両端(0.57は遅い側、1.52は良好側の上限に近い)を具体的な障害調査の文脈で再現している。さらに16章はIPC差の原因をLLCヒット率の差にまで分解しており、6章が「高い/低いの基準はプロセッサによって異なり実験的に判断すべき」と述べる注意書きを、実際の原因分析の手順(PMCでIPCとLLC%を同時に見る)として具体化した実例になっている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.3.7, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.5) ## 未解決の問い - ヘテロジニアスアーキテクチャ(big.LITTLE、P/E コア混在)では IPC をどのコア基準で正規化すべきか。 - マルチスレッド/SMT 環境では IPC がスレッド間でどう干渉するか。 - GPU における IPC の類比は何か(SIMD スループット、ワープ効率、メモリ帯域利用率など)。 - CPI と IPC の使い分け(Linux/perf コミュニティ vs Intel 等ベンダー)は、ツールやドキュメントをまたいだ解釈のブレをどこまで生んでいるか。書籍の pmcarch(8)/tlbstat(8) のような具体ツール実装を横断して確認したい。 - `perf stat` のシャドウ統計は IPC 以外にどのようなイベント組み合わせで何が表示されるか(13章はIPCの例のみを示す)。網羅的なリストは他章・man page で確認できるか。 - 16章はIPC差(2.6倍)の原因をLLCヒット率の差(3.0倍相当)に帰着させたが、両者の倍率が一致しない(2.6倍対3.0倍)理由は明示されていない。ハイパースレッド競合等の副次要因がどの程度寄与しているか、より詳細な分解が必要。 ## 関連 - ソース: [[@2017__brendangregg.com__CPU Utilization is Wrong]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] - 概念: [[CPU利用率]] / [[ハードウェアカウンタ]] / [[メモリバウンド]] / [[継続的プロファイリング]] / [[コンテキストスイッチ]] - エンティティ: [[Brendan Gregg]] / [[perf]] - 別概念(混同注意): [[IPCメトリクス]](Inter-Process Communication Metrics) ## 出典 - [[@2017__brendangregg.com__CPU Utilization is Wrong]]（IPC の診断基準・Linux perf による計測法・%CPU との対比） - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]](§6.3.7 IPC/CPI・§6.6.11 pmcarch・§6.6.12 tlbstat・§6.6.13.6 perf stat による IPC 計測例) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]](§13.8.5 perf stat のシャドウ統計としてのIPC自動表示) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.5, §16.1.8(VM対コンテナのIPC・LLCヒット率実測比較)