コンピュータとCPUの性能の定義および測定方法について見ていきましょう。

本記事の内容は浦項工科大学校のCSED311の内容に基づき、
授業で扱われなかったいくつかの内容を追加して構成しました。

コンピュータの「性能」とは？

私たちはソフトウェアやシステムの性能を判断するとき、「速い」という言葉をよく使います。しかし、正確には何が速いのでしょうか？システムの性能を定義する測定値は大きく分けて2つあります。

1つ目はレイテンシ(Latency) です。レイテンシとは、1つのリクエストが開始から完了するまでにかかる時間を意味します。例えば、CPUが1つの命令を実行するのにかかる時間を考えると、メモリからデータを読み込むload命令がある場合、その命令が発行されてから結果がレジスタに届くまでの時間がレイテンシです。

2つ目はスループット(Throughput) です。単位時間あたりにプロセッサが処理できる作業量を意味します。大量のソースコードをコンパイルするなど、複数の作業を同時に処理する場合にスループットが特に重要になります。

一見するとThroughput = 1/Latencyの関係が成り立ちそうです。各命令のレイテンシが短くなれば、自然とスループットも増えるはずですから。しかし、そうではありません。代表的な例がスーパースカラプロセッサで、この場合は実行ユニットが複数あるため、一度に複数の作業を処理できます。個々の命令の所要時間(Latency)はそのままなのに、Throughputだけが向上するのです。

時間の測定

CPUの性能とは結局、時間の問題です。レイテンシが短ければリクエストにかかる時間が減るので性能が向上し、スループットが高ければ同じ量の作業をより早く終えられるので、やはり性能が高いです。CPUで時間を測定する方法もいくつかあり、UNIXの timeコマンドでは以下の用語を使用します。

Wall Clock Time(Elapsed Time) は、プログラムの実行ボタンを押した時点から結果が出るまでに「実際に」経過した時間です。ユーザーが体感する時間なので最も直感的ですが、この時間には測定対象のプログラムだけでなく、他のプログラムの処理、割り込みなど他の要素が含まれています。
User CPU Timeは、CPUが純粋に自分のコードを実行するのに費やした時間です。自分が書いた関数、ループ、演算などが実際にCPUで実行された時間のみが該当します。
System CPU Timeは、自分のコードが直接実行されたわけではありませんが、自分のコードの実行のためにOSカーネルが動作した時間を意味します。ファイルの読み込み、メモリの割り当て、ネットワークパケットの送信などのシステムコールがこの時間に含まれます。

Elapsed TimeからUser CPU TimeとSystem CPU Timeを引くと少し残りますが、これは自分のプログラムとは無関係に消費された時間です。他のプロセスがCPUを占有していたり、ディスクI/Oを待っていたり、スケジューラによって自分のプロセスの処理順序が後回しにされた時間などがここに含まれます。

したがって、プロセスの性能を測定・報告する際には、これらのうちどれを測定したのかを正確にする必要があります。User CPU Timeを見れば自分のコード自体の効率を判断でき、Wall Clock Timeを見ればシステム上でユーザーが実際に待つ時間を測定できます。

CPUクロックとFLOPS

性能に大きな影響を与える要素として、CPUのクロック(Clock) があります。 CPUクロックとは、CPU内部ですべての動作のタイミングを合わせる信号です。1GHzなら 1秒に10億回のティックが発生し、1ティックの長さは1ナノ秒になります。4GHzなら 0.25ナノ秒です。CPUのすべての演算はこのティックに合わせて進行するため、クロックが速ければ同じサイクル数が必要な作業をより短い時間で完了できます。

しかし、クロックだけでCPUの性能を評価することはできません。プロセッサ性能の鉄則(Iron Law)によると、プログラムの実行時間は3つの要素の積で表現できます。

cpu time = (time/cycle) x (cycles/instruction) x (instructions/program)

ここでcycles/instruction(命令あたりのサイクル数)をCPIと呼び(サイクルあたりの命令数はIPC）、1秒あたりの命令数をIPSと呼びます。通常、1秒あたり 100万命令を基準としてMIPS(Million Instructions Per Second)と呼びます。

鉄則を見ると、クロック周期(time/cycle)が性能にそのまま掛け算されるため、クロック数を上げるだけで性能が向上しそうですが、クロック数を上げるとパイプラインが深くなりCPIが上昇して、かえって性能が低下する場合もあります。また、 ISAを簡素化してCPIを下げると、同じ処理により多くの命令が必要になる場合があります。したがって、クロック、CPI、命令数の3つのうち1つだけを見てプログラムの性能を判断することはできず、CPUを最適化する際には3つの要素のバランスを常に一緒に考える必要があります。

科学計算分野では、FLOPS(Floating Point Operations Per Second) という指標で性能を算出することもあります。FLOPSは、コンピュータが1秒間に実行できる浮動小数点演算の数を数値で表したもので、物理シミュレーション、気象予測、行列演算などの科学計算分野では浮動小数点演算が核心的であるため、整数演算速度の代わりに浮動小数点演算速度を指標として使用します。2026年現在、一般的なスマートフォンは1〜10テラフロップス、気象庁や研究所で使用されるスーパーコンピュータは数百ペタフロップス程度の性能を持っています。

時間以外の評価基準

プロセッサの演算において主要な性能評価指標は時間ですが、実行時間だけが性能の指標になるわけではありません。現実ではプロセッサは電力を消費し熱を発生させるため、これを最小化することも重要な評価指標になります。

また、実装コストや信頼性、セキュリティもプロセッサを評価する上で重要な指標です。いくら優れたプロセッサでも、設計や製造にコストがかかりすぎれば実用的ではありません。システムがどれだけ安定的にエラーなく動作するかも重要です。例えば、プロセッサを任意にオーバークロック(Overclock)して強制的に実行速度を上げれば実行速度は速くなりますが、信頼性は低下するでしょう。

プロセッサのセキュリティとは、サイドチャネル攻撃の防御やメモリ保護などを意味し、セキュリティ機能を追加すると実行時間が長くなる可能性があるため、これもプロセッサ性能におけるトレードオフになります。一例として、2017年のMeltdown/ Spectreセキュリティ脆弱性事件では、これを解決する過程でOSの複数の最適化を放棄し、性能が大幅に低下した事例があります。このような脆弱性が存在するCPUとそうでないCPUを、こうした考慮なしに評価するのは適切ではないでしょう。

アムダールの法則

アムダールの法則は、プログラムの一部をどれだけ高速化しても、全体の性能向上はその部分が占める割合に制限されるという法則です。

$$T_{\text{new}} = T_{\text{old}} \times \left((1-f) + \frac{f}{S_f}\right)$$

$$S_{\text{overall}} = \frac{T_{\text{old}}}{T_{\text{new}}} = \frac{1}{(1-f) + \frac{f}{S_f}}$$

上記の数式でfは改善可能な部分が全体に占める割合であり、 $S_{\text{f}}$はその部分をどれだけ高速化したかを表します。

例えば、プログラム実行時間の80%を占める部分を4倍高速化した場合、実行時間の向上は$\frac{1}{(1-0.8) + 0.8/4} = \frac{1}{0.2 + 0.2}$ = 2.5倍になります。プログラムの大部分を占める部分を4倍も高速化したのに、全体では2.5倍しか速くなっていません。極端にその部分を無限に高速化して実行時間を0にしたとしても、残りの20%は決して減らないため、5倍が限界です。

プログラムの性能測定

プログラムの性能を測定するために、私たちはコンピュータに一連の作業を実行させる ベンチマークを実行します。どのプログラムが良いベンチマークであるかは、以下の基準で評価できます。

どのような作業を実行するか、ワークロードを明確に定義する必要があります。
時間やスループットなどの具体的な数値指標を出す必要があります。
再現可能でなければなりません。同様の条件で再実行すれば、同様の結果が出る必要があります。
移植可能でなければなりません。様々なプラットフォームに移植して複数のシステムで実行できてこそ、ベンチマークによるシステム間の結果比較が意味を持ちます。
意味のある出力を生成するなどの方法で、ベンチマークが正確に実行されたかを検証できる必要があります。ベンチマークがこのような正確性を確認しなければ、コンパイラが無意味な演算を省略してしまうなど、実際の性能とは無関係に高い数値を生み出す可能性があります。
どのデバイスで実行でき、どの最適化を使用できるかを明確にする必要があります。そうしなければ、ベンダーごとに有利な条件でベンチマークを実行して数値を水増しする可能性があります。

現在、最も代表的なベンチマークにはSPECがあります。SPECはCPUの集約的な演算性能を測定する業界標準で、プロセッサ、メモリサブシステム、コンパイラに負荷をかけます。

業界ではなく一般消費者市場では、Cinebench、Geekbench、3DMarkなど、実際のコンピュータ使用環境に近い環境で全体システムの性能を測定するベンチマークが多く使われています。

ベンチマーク性能の平均化

ベンチマーク結果を総合する際は、通常、様々なベンチマークを複数回実行して平均を取る方法で評価します。ただし、このような平均の取り方にもいくつかの方法があります。

算術平均

算術平均(Arithmetic Mean) は、日常生活で最もよく使われる平均方式で、実行時間をすべて足して個数で割る方式です。ただし、この方法では実行時間が長いプログラムが平均を支配するという問題があります。

加重算術平均(Weighted Arithmetic Mean) は、この算術平均の問題を解決するために、各プログラムの実行頻度を重みとして反映して算術平均を取る方式です。よく使うプログラムの性能がより大きく反映され、実際の使用パターンにより近い平均が得られます。

幾何平均

幾何平均(Geometric Mean) は、すべての値を掛け合わせてn乗根を取る平均方式です。前述のSPECがこの方式を採用しています。幾何平均の最大の利点は、各プログラムの重み比率に関係なく一貫した結果を出すことです。

例えば、以下のような2台のマシンとプログラムがあるとしましょう。

マシン	プログラムA	プログラムB
X	10秒	100秒
Y	20秒	50秒

Xを基準に性能を正規化すると、マシンYはA = 2.0、B = 0.5になります。算術平均を取ると1.25になるため、マシンYの方が遅く見えます。逆にマシンYを基準に正規化すると、マシンXはA = 0.5、B = 2.0になります。同様に算術平均を取ると1.25なので、両方とも相手より1.25倍遅いという矛盾した結果が出ます。

幾何平均を使えばこの問題はありません。マシンX基準でマシンY： $\sqrt{2.0 \times 0.5}$ = 1.0、マシンY基準でマシンX： $\sqrt{0.5 \times 2.0}$ = 1.0。両方とも1.0なので、2台のマシンの性能は同等であるという一貫した結論が得られます。

ただし、幾何平均は実行時間の総計とは直接的な関連がないため、平均結果の直感的な解釈が難しいという欠点があります。

調和平均

調和平均(Harmonic Mean) は、各値の逆数の算術平均の逆数です。比率指標を平均する際に適しています。例えば、MIPSやFLOPSのように「単位時間あたりのスループット」を平均する必要がある場合、算術平均を使うと歪みが生じます。速度が10MIPSのプログラムを1秒実行し、100MIPSのプログラムを1秒実行したとして、算術平均が55MIPSだと言えば、実際の性能より平均が過大評価されていることになります。調和平均は遅い方により重みを与えるため、比率指標でより正確な平均を出します。

コンピュータの性能測定