# 性能測定 ## 定義 性能測定とは、目の前にある計算機システムの姿を正確に捉えつづけるための技芸(art)である。Raj Jain の著書 "The Art of Computer Systems Performance Analysis" が指摘するように、性能評価は機械的に行えるものではなく、対象システムへの深い理解とモデル化・ワークロード・手法・ツールの慎重な選択を要する(Source: [[@2013__JPUG__性能測定道 事始め編]])。性能測定は単独の技術ではなく、モデル化(Modeling)・計測(Measurement)・シミュレーション(Simulation)という3つの基本形の組み合わせとして成立する。この3つは互いに検証(validate)し合う関係にあり、少なくとも2つ以上を使いこなすことが肝心とされる(Source: [[@2013__JPUG__性能測定道 事始め編]])。 - **モデル化**: 測定対象の内部動作原理を理解し、性能に影響する要素を選び出して数式化すること。科学的アプローチの原点であり、モデル化ができれば実際の計測前に性能を予測できる。適切なモデルは測定対象の理解そのものであり、モデル化が性能測定の全てを決めるといっても過言ではない。 - **計測**: モデル化の「しもべ」であり、モデルなき計測は意味を成さない。モデルが計測結果の正しさを裏付け、計測がモデルの正しさを確認するという相互検証の関係にある。 - **シミュレーション**: まだ存在しないハードウェアや未実装のソフトウェアの性能を、模した環境(専用ハードウェアやソフトウェアによるシミュレーション実行)で予測する手段。「もしもこうだったら?」という仮定を分析する技術であり、システムの一部を意図的に「端折る」行為でもあるため、計測・モデル化による正しさの確認が重要になる。 目的から性能測定の手法を導出する順序(測定するワークロード→測定するメトリック→メトリックのモデル化→測定環境→測定手段→計測実施→計測結果とモデルの照合)が推奨され、目的なきベンチマークツールの実行(「NG: ベンチマークツールを実行してみるだけ」)は戒められる(Source: [[@2013__JPUG__性能測定道 事始め編]])。 ## 横断的知見 - 「事始め編」が提示したモデル化・計測・シミュレーションの三角形のうち、続編「実践編」は計測(Measurement)を深掘りする。計測の核心は「測定したい量(メモリアクセス回数)と実測できる量(実行時間)を比例させる」ことにあり、CPUの命令パイプライン実行・スーパースカラ実行・プリフェッチ・分岐予測といった性能最適化機構がこの比例関係を崩すため、意図的にこれらを無力化する(ニート化する)コードを書く必要がある(Source: [[@2014__JPUG__性能測定道 実践編]])。これは「事始め編」で説いた「計測はモデル化のしもべ」というテーゼの具体例であり、CPU内部動作のモデルを理解して初めて正しい計測コードが書けることを示す。 - AWS EC2上でのライブ実測では、L1Dキャッシュのアクセスレイテンシが8.23クロック(Wikipedia調べの理論値3クロックの約2.7倍)、L2キャッシュが24.6クロック(理論値8クロックの約3倍)と、実測値が教科書的な理論値を一貫して上回った。講演者は口頭説明でこの差異の要因を明言しており、AWS EC2が仮想マシン環境であるためリアルなハードウェアのキャッシュレイテンシがそのまま見えているわけではないこと、同じ測定プログラムを物理マシン上で実行すると文献値とほぼ一致することを付言した。すなわち、モデル化された理論値と実測値の乖離それ自体が「対象システムが仮想化されているか」を判定するシグナルになりうるという、計測とモデル化の相互検証関係(事始め編の中心テーゼ)の具体的な応用例である(Source: [[@2014__JPUG__性能測定道 実践編]])。 - 主記憶アクセスのレイテンシは、アクセス領域のサイズが大きくなるほど悪化し続ける。これはOSがページ管理のために保持するページテーブルのlookupコストが、アクセス領域の拡大とともに積算されるためである(Source: [[@2014__JPUG__性能測定道 実践編]]、口頭説明)。キャッシュ階層の境界(L1/L2/L3/主記憶)だけでなく、ページテーブル管理という別のレイヤーの効果もメモリアクセスレイテンシの実測値に影響することを示す。 - 単一マシン・単一プロセス(DB/OS)を対象とする「性能測定道」の哲学(モデル化が計測に先行し、対象の内部動作原理の理解が測定の正しさを担保する)は、分散コンピューティングコンティニュウム(DCCS)のような異種・多層システムを対象とする [[@2026__arXiv__A Taxonomy of Performance Metrics for the Distributed Computing Continuum]] とは前提が異なる。後者はモデル化そのものよりも「メトリクスをどの範囲(Single-Node/Multi-Node/Full System/Full App)から、いつ(Operational/Experimental)、どう(Standard/Custom/Experimental Instrumentation)取得するか」という**取得可能性(feasibility)の分類**に主眼を置く。これは、対象システムが単一ノードで完結せず、計装点自体が分散している場合には「モデル化→計測」という単純な順序だけでは測定戦略を規定しきれない、という規模の違いに起因する知見である(Source: [[@2013__JPUG__性能測定道 事始め編]], [[@2026__arXiv__A Taxonomy of Performance Metrics for the Distributed Computing Continuum]] §3.2)。 - 「性能測定道」がCPUのパイプライン実行・分岐予測などの最適化機構を意図的に無力化して比例関係を作り出すのに対し、DCCSタクソノミーの多くのメトリクス(Execution Time、Network Latency等)は既存の標準テレメトリ(OpenTelemetry等)からそのまま取得できる Standard Telemetry に分類される。前者は「正しく測るために対象を単純化する」戦略、後者は「複雑な対象からでも既存計装で拾える指標を選ぶ」戦略であり、対象システムの規模に応じて測定へのアプローチそのものが変わることを示す(Source: [[@2014__JPUG__性能測定道 実践編]], [[@2026__arXiv__A Taxonomy of Performance Metrics for the Distributed Computing Continuum]] §4.1)。 - 「事始め編」が「性能評価は科学ではなく技芸(art)である」というテーゼを Raj Jain の著書に帰して要約していたが、原典である [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] を直接確認すると、この主張の根拠は抽象論ではなく、同一の測定データを「平均」「基準システム B に対する比」「基準システム A に対する比」のいずれで比較するかによって結論(互角/A が優位/B が優位)が反転するという具体例(比率ゲーム、Example 1.7)である。つまり本書における「技芸」とは、モデル化・計測・シミュレーションの手法選択だけでなく、測定後の**比較・提示方法の選択**にも及ぶ、より広い射程を持つ主張である(Source: [[@2013__JPUG__性能測定道 事始め編]], [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] §1.2)。 - 本書はまた、性能アナリストが実務で踏む誤り(common mistakes)と、自システムの優位性を示すための意図的な小細工(games、比率ゲームはその一例)を区別する。「性能測定道」の「モデルなき計測は意味を成さない」というテーゼは前者(技法への無理解に起因する誤り)の防止策にあたるが、後者(意図的なゲーム)への対処は測定技法そのものではなく、比較・報告のプロセス設計の問題であり、「性能測定道」では扱われていない層である(Source: [[@2013__JPUG__性能測定道 事始め編]], [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] §1.2)。 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] が「性能評価は技芸である」というテーゼを比率ゲーム(Example 1.7)という具体例で語ったのに対し、同書 [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 2 Common Mistakes and How to Avoid Them]] はこのテーゼを実務手順として展開する。第1章が指摘した「技芸性」は測定後の比較・提示方法の選択に及ぶものだったが、第2章はさらに測定に先立つ目標設定・システム境界定義・メトリクス選定・要因選定を含む10ステップの体系的アプローチ(§2.2)を提示し、22件のよくある誤り(§2.1)をこの手順からの逸脱として整理する。第1章が性能評価という営みの「技芸性」を主張する層だとすれば、第2章はその技芸を可能な限り手順化・チェックリスト化(Box 2.1・Box 2.2)する層であり、両者は「性能評価は機械的に行えない」という同じ主張への相補的なアプローチ(定性的な事例提示 対 手順の明文化)である(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] §1.2, [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 2 Common Mistakes and How to Avoid Them]] §2.1-2.2)。 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 3 Selection of Techniques and Metrics]] は、第1・2章が「性能評価は技芸である」というテーゼを事例(比率ゲーム)や手順(10ステップ)として展開したのとは異なる粒度で、モデル化・シミュレーション・測定という3技法そのものを比較する規準表(Table 3.1: 開発段階・所要時間・道具・精度・トレードオフ評価のしやすさ・コスト・売り込みやすさの7規準、重要度順)を与える。これは「性能測定道」が示すモデル化→計測→シミュレーションの相互検証の三角形(既出)を、技法選択という意思決定問題として明文化したものと読める。「性能測定道」が計測を「モデル化のしもべ」と位置づける主従関係を語るのに対し、第3章は開発段階(実物が存在しない新規システムでは測定は選択肢になりえず、解析モデリングかシミュレーションしか選べない)を最重要規準とする多基準比較として技法選択を相対化し、さらに「3つの検証則」(いずれの技法の結果も他の2技法で検証されるまで信用しない)によって、三角形の相互検証という発想を明示的なルールへ格上げする(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 3 Selection of Techniques and Metrics]] §3.1, [[@2013__JPUG__性能測定道 事始め編]])。 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] は冒頭で「モニタリングは性能測定における最初の鍵となるステップである」と明言し、第1〜3章が確立した「性能評価は技芸である」という規範論・技法選択論を、実際にデータを取得する道具(モニタ)の設計論へと接続する。第3章のTable 3.1が3技法(モデル化・シミュレーション・測定)を比較する意思決定枠組みだったのに対し、第7章はそのうち「測定」を選んだ後に必然的に生じる下位問題──どの実装水準(ソフトウェア/ハードウェア/ファームウェア)・どの起動機構(事象駆動/サンプリング)のモニタを使うか──を扱う。つまり第3章の技法選択(what)と第7章のモニタ選択(how)は、同じ「性能測定は技芸である」というテーゼの異なる意思決定レイヤーに位置する(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 3 Selection of Techniques and Metrics]] §3.1, [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.2)。 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] は、第7章が確立したモニタ選択論(実装水準・起動機構)を前提としつつ、「モニタを設計せず、既に別目的(課金)で稼働しているログを転用する」という第3の道を示す。これは第3章のTable 3.1・「3つの検証則」が想定する「意図的に選んだ技法を実施する」という能動的な意思決定モデルには収まらない――課金ログの活用は技法選択ではなく、既存のデータ収集インフラを性能解析という別目的へ**事後的に転用する**判断であり、「性能評価は技芸である」というテーゼに、モニタを設計する技芸(第7章)とは異なる、既存資産を見出し転用する技芸という新たな層を加える(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] §7.2, [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] §8.3)。 - **計算機アーキテクチャの教科書のCPU性能方程式(CPU時間=命令数×CPI×クロックサイクル時間)は、「性能測定道」の三角形における『モデル化』と『計測』の関係を、プロセッサ設計という具体的な対象で例証する**: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]] §1.9は、CPU時間を命令数(IC)・命令あたりクロックサイクル数(CPI)・クロックサイクル時間の3項の積へ分解するモデルを提示したうえで、「CPIiは表から計算するのではなく実測されるべきである。パイプライン効果・キャッシュミス等のメモリシステムの非効率を含める必要があるからだ」と明言する。これは「性能測定道」が説く「モデル化ができれば実際の計測前に性能を予測できるが、計測はモデル化の正しさを裏付けるしもべである」という相互検証の関係を、プロセッサ設計という具体的対象で例証する——3項への分解自体はモデル化(対象の理解)の産物だが、各項(特にCPI)の値はシミュレーションまたはハードウェアカウンタによる計測なしには得られない。本書はさらに、モダンなプロセッサが命令実行数・クロックサイクル数の両方を数えるカウンタを備え、これによりコードの一部区間に実行時間・命令数を対応づけられると述べており、これは「性能測定道」実践編が使うCPUの性能カウンタによる実測(L1D/L2キャッシュレイテンシの実測等)と同じ計装原理に立脚する。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]] §1.9, [[@2013__JPUG__性能測定道 事始め編]], [[@2014__JPUG__性能測定道 実践編]]) - **本書はDVFS・オーバークロックのような電力管理機構が測定の再現性を損なうことを明示し、対策として機構を無効化するという、「性能測定道」実践編がCPUのパイプライン最適化機構に対して取った戦略と同型の解決策を独立に導出する**: §1.9は、動的電圧周波数スケーリング(DVFS)やターボモードのような電力効率化技法がクロック速度をプログラム実行中に変動させるため性能方程式の適用を困難にすると指摘し、「単純な対処法はこれらの機能を無効化して結果を再現可能にすることである」と述べる。これは「性能測定道」実践編(Source: [[@2014__JPUG__性能測定道 実践編]])が、CPUのパイプライン実行・スーパースカラ実行・プリフェッチ・分岐予測を意図的に無力化するコードを書くことで「測定したい量と実測できる量を比例させる」戦略と、対象こそ異なる(電力管理機構 対 命令レベル並列性機構)ものの、「測定を歪める最適化機構を意図的に無効化する」という同一の方法論に、独立に到達している。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]] §1.9, [[@2014__JPUG__性能測定道 実践編]]) - **GPU の命令性能測定では、対象を固定するだけでなく、周波数と電力状態を測定条件として記録する必要がある**: Hopper のマイクロベンチマークはスループットを実時間で計算し、H800 のランダム値行列で350W電力上限による周波数低下を確認した。理論ピークとの比較には、命令形式・データ初期値・電力制約を含む実行条件の明示が不可欠である。(Source: [[@2024__arXiv__Benchmarking and Dissecting the Nvidia Hopper GPU Architecture]]) - **GPU 性能測定は、命令レベルの正確さと実ワークロードの代表性を分けて設計する必要がある**: Blackwell の研究は `%clock64`、PTX 個別ファイル、生成 SASS の確認で命令挙動を分離しつつ、FP8 D-GEMM と Transformer 推論で実効性能・電力へ橋渡しした。命令レベルで GB203 が低精度 MMA に有利でも、D-GEMM では H100 が0.887対0.233 TFLOP/sとなるため、単一の測定粒度から世代全体を評価してはならない。(Source: [[@2024__arXiv__Benchmarking and Dissecting the Nvidia Hopper GPU Architecture]], [[@2025__arXiv__Dissecting the NVIDIA Blackwell Architecture with Microbenchmarks]]) - **性能測定の再現性には電力だけでなくソフトウェア経路の固定も必要である**: 同じ GPU でも PTX から QMMA/OMMA/HMMA への変換、CUDA の精度形式、TensorRT の Best 経路、行列形状で結果が変わる。ハードウェア SKU、ドライバ・CUDA/TensorRT、カーネル、ワークロード形状、電力状態を測定条件として記録する必要がある。(Source: [[@2025__arXiv__Dissecting the NVIDIA Blackwell Architecture with Microbenchmarks]]) - **モバイルプラットフォームの性能測定では、部品単体の速度ではなく利用モデル別の性能・電力を同時に測る必要がある。** - 第2世代Centrinoの評価は、オフィス、生産性、科学計算、DVD/CD再生、アイドルを対象に、CPU、GMCH、ICH、メモリ、無線の機能と消費電力を比較する。（Source: [[@2005__Intel Technology Journal__Performance and Power Consumption for Mobile Platform Components Under Common Usage Models]]） - **シミュレーションとベンチマークの結果が一致しない箇所は、測定条件を追加で開示すべき検証点になる。** - Intel 915の3Dグラフィックス論文は、導入部の前世代比と表の比較値が一致しないため、解像度、ドライバ、測定条件、比較対象の特定が必要になる。（Source: [[@2005__Intel Technology Journal__High-Performance Graphics and TV Output Comes to the Second-Generation Intel Centrino Mobile Technology Platform]]） ## 未解決の問い - I/O REPLAY のようなワークロード再現によるシミュレーション手法は、HDD/SSD以外のモダンなストレージ(NVMe SSD、永続メモリ等)やネットワーク・GPU等の他リソースにどこまで一般化できるか。 - 未書き込みのEBSボリュームでIOPSが公称値より大幅に低くなる(講演デモでは1スレッド時に公称4000IOPSに対し実測70IOPS程度)現象について、講演者はAmazon側のバックエンドによる制御を推測として述べたのみで、確定的な原因(実際にそのような制御が存在するか、単なる初回アクセスのウォームアップ効果か)は未検証。 - [[@2026__arXiv__A Taxonomy of Performance Metrics for the Distributed Computing Continuum]] が提示する acquisition scope/phase/method の3次元分類は「性能測定道」のモデル化・計測・シミュレーションの三角形とどう対応づけられるか。前者はメトリクスをどこから・いつ・どうやって取得するかという運用上の実装可能性を分類する枠組みであり、後者は測定手法そのものの認識論的な三分類である。両者を統合すれば「このメトリクスは技法として計測かシミュレーションか」に加えて「実運用でどこまで安価に取得できるか」を同時に評価できる可能性がある。 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] の比率ゲーム(Example 1.7)が示す「比較・提示方法自体が結論を左右する」という問題は、「性能測定道」のモデル化・計測・シミュレーションの三角形や DCCS タクソノミーの取得可能性分類のどこに位置づけられるか。いずれの既存枠組みも測定・取得の正しさは扱うが、測定後の比較方法の妥当性を評価する観点を明示的には持たない。 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 3 Selection of Techniques and Metrics]] の Table 3.1(技法選択の7規準)と、[[@2026__arXiv__A Taxonomy of Performance Metrics for the Distributed Computing Continuum]] の acquisition scope/phase/method の3次元分類は、どちらも「何を基準に測定手段を選ぶか」を扱うが、前者は解析モデリング・シミュレーション・測定という3技法間の選択、後者は測定という1技法の内部でのメトリクス取得方法の選択を扱う点で対象の粒度が異なる。両者を接続し、「技法選択→技法内でのメトリクス取得方法選択」という2段階の意思決定モデルに統合できるか。 - CPU性能方程式(IC×CPI×クロックサイクル時間)における各項の相互依存性(クロックサイクル時間はハードウェア技術と構成、CPIは構成とISA、命令数はISAとコンパイラ技術にそれぞれ依存する)は、DCCSタクソノミーのようなマルチノードシステムのメトリクス取得可能性分類にどこまで一般化できるか。単一プロセッサでは3項に明快に分解できる性能が、分散システムでは同様に独立した「計測すべき項」の集合へ分解できるか。 - GPU の実時間スループット測定において、電力制限・動的周波数・温度・冷却条件をどのように統制すれば、異なる施設と GPU SKU の結果を比較可能にできるか。 - PTX/SASS の命令レベル指標と、GEMM・Transformer 推論の end-to-end 指標を、同じモデルで因果的に対応づける実験計画はどう設計すべきか。 ## 関連 - [[@2013__JPUG__性能測定道 事始め編]] — 初出ソース。モデル化・計測・シミュレーションの三角形と、HDD/待ち行列/I/O REPLAYの実例 - [[@2014__JPUG__性能測定道 実践編]] — 続編ソース。CPUの性能最適化機構を無力化するメモリアクセスレイテンシ測定と、micbench・PerfMongerを用いたI/O性能測定の実践 - [[@2026__arXiv__A Taxonomy of Performance Metrics for the Distributed Computing Continuum]] — DCCS向け性能メトリクスタクソノミー。acquisition scope/phase/methodの3次元分類 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] — 「性能評価は技芸である」というテーゼの原典。比率ゲーム(Example 1.7)の初出 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 2 Common Mistakes and How to Avoid Them]] — 性能評価によくある22の誤りと、10ステップの体系的アプローチ(Box 2.1・Box 2.2) - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 3 Selection of Techniques and Metrics]] — 3技法(解析モデリング・シミュレーション・測定)の選択規準(Table 3.1)と3つの検証則 - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] — 「モニタリングは性能測定の最初の鍵となるステップ」。測定という技法を選んだ後のモニタ選択(実装水準・起動機構)を論じる - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] — モニタを設計せず既存の課金ログを転用するという第3の道。「性能評価は技芸である」というテーゼに既存資産の転用という層を加える - [[性能メトリクスの選定]] — 第3章から派生した姉妹概念。メトリクス選定・分類そのものを扱う - [[Raj Jain]] — *The Art of Computer Systems Performance Analysis* の著者 - [[早水悠登]] — 講演者。micbench・PerfMongerの開発者 - [[喜連川優]] — 講演内で引用された OLTP モデル化論文の共著者 - [[micbench]] — 実践編で用いられたマイクロベンチマークツールセット - [[PerfMonger]] — 実践編で用いられた性能モニタリング・可視化ツール - [[分散コンピューティングコンティニュウム]] — DCCSの定義 - [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]] — CPU性能方程式(IC×CPI×クロックサイクル時間)による測定対象の分解と、DVFS等の電力管理機構を無効化して再現性を確保する実践(§1.9) - [[@2025__arXiv__Dissecting the NVIDIA Blackwell Architecture with Microbenchmarks]] — Blackwell と Hopper の PTX/SASS、Tensor Core、メモリ階層、GEMM、Transformer 推論の比較測定 ## 出典 - [[@2013__JPUG__性能測定道 事始め編]] - [[@2014__JPUG__性能測定道 実践編]] - [[@2026__arXiv__A Taxonomy of Performance Metrics for the Distributed Computing Continuum]] - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 1 Introduction]] - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 2 Common Mistakes and How to Avoid Them]] - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 3 Selection of Techniques and Metrics]] - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 7 Monitors]] - [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 8 Program Execution Monitors and Accounting Logs]] - [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]] §1.9 - [[@2025__arXiv__Dissecting the NVIDIA Blackwell Architecture with Microbenchmarks]]