パフォーマンスとは何ですか?
パフォーマンス = 1/応答時間
時間の逆数、コンピュータのパフォーマンスを測定するための基準が必要です。この規格には 2 つの主要な指標があります。
1. 応答時間または実行時間。応答時間のパフォーマンス指標を向上させたい場合は、コンピューターの「動作を速くする」と理解できます。
2. スループット (Throughput) または帯域幅 (Bandwidth)、この指標を改善したい場合は、コンピューターを「より多く動かす」ことと理解できます。
したがって、応答時間とは、プログラムの実行にかかる時間を指します。費やす時間が短いほど、自然なパフォーマンスが向上します。
スループット レートは、特定の時間枠内で処理できる処理の数を指します。ここでの「物」とは、コンピュータ内で処理されるデータ、または実行されるプログラム命令です。
パフォーマンスを向上させるにはどうすればよいですか?
物を動かすのに比べて、応答時間が短く、速く走れば、往復の回数が増え、より多くの移動が可能になります。したがって、プログラムの応答時間を短縮すると、一般にスループットが向上します。応答時間を短縮する以外に何か方法はあるでしょうか? もちろん、たとえば、さらに数人の人を見つけて一緒に移動することもできます。これは、8 コアと 16 コアを備えた最新のサーバーと同様です。より多くの人員とより多くの能力を備え、同時にデータを処理できるようになると、単位時間あたりにより多くのデータを処理できるようになり、スループット率は自然に向上します。
スループットを向上させる方法はたくさんあります。ほとんどの場合、必要なのはマシンを追加し、ハードウェアを積み上げるだけです。しかし、応答時間の改善はそう簡単ではなく、
CPUクロック
しかし、時間で測ると 2 つの問題があります。
1つ目は、時間が「正確」ではないということです。今回は 45 ミリ秒、次回は 53 ミリ秒かかった可能性があります。「ストップウォッチをつまむ」のと同様の方法で時間をカウントし、プログラムの実行終了時刻からプログラムの実行開始時刻を引いた時間を記録します。この時間は壁時計時間または経過時間とも呼ばれ、プログラムの実行中に壁に掛けられた時計が消えた時間です。ただし、プロセススイッチがあるため。一部のプログラムは、実行中にネットワークとハードディスクからデータを読み取り、ネットワークとハードディスクがデータを読み取ってメモリと CPU に渡すのを待つ必要がある場合があります。したがって、特定のプログラムの実行時間を正確にカウントし、2 つのプログラムの実際のパフォーマンスを比較するには、これらの時間を除外する必要があります。
Linux には time と呼ばれるコマンドがあり、同じ実時間でプログラムが実際に CPU に費やす時間を計算するのに役立ちます。
単純に time コマンドを実行してみましょう。3 つの値が返されます。1 つ目は実時間、いわゆる実時間、つまりプログラムの実行プロセス全体で経過した時間です。2 つ目はユーザー時間、つまり CPU が実行している時間です。プログラム 、ユーザー モードで命令を実行する時間、3 番目は sys 時間で、CPU がプログラムを実行し、オペレーティング システム カーネルで命令を実行している時間です。プログラムが実際に費やした CPU 実行時間 (CPU 時間) は、ユーザー時間とシステム時間を加算したものです。
(base) [root@localhost shapan_alg]# time seq 1000000 | wc -l
1000000
real 0m0.037s
user 0m0.014s
sys 0m0.004s
(base) [root@localhost shapan_alg]#
私が示した例では、プログラムに実際には 0.101 秒かかったことがわかりますが、CPU 時間は 0.031+0.016 = 0.047 秒でした。プログラムの実行時間の半分未満が実際にプログラムに費やされます。
第 2 に、たとえ CPU 時間があったとしても、2 つのプログラムのパフォーマンスの違いを直接「比較」できるとは限りません。同じコンピューターであっても、CPU は全負荷で実行される場合とアンダークロックで実行される場合があり、当然アンダークロックの方が時間がかかります。
CPU に加えて、時間のパフォーマンス指標は、マザーボードやメモリなどの他の関連ハードウェアの影響も受けます。したがって、私たちが認識できる「時間」という指標を分解し、プログラムの CPU 実行時間を CPU クロック サイクル数 (CPU Cycles) とクロック サイクル時間 (Clock Cycle) の積に変換する必要があります。
プログラムの CPU 実行時間 = CPU クロック サイクル × クロック サイクル タイム
パフォーマンスを向上させる最も簡単な解決策は、自然にクロック サイクル タイムを短縮する、つまりメイン周波数を上げることです。つまり、より優れた CPU に変更するだけです。ただし、これは私たちソフトウェア エンジニアが制御できないことなので、乗算の別の要素である CPU クロック サイクル数に注意を移しました。プログラムに必要な CPU クロック サイクル数を減らすことができれば、プログラムのパフォーマンスも向上します。
CPU クロック サイクル数については、別の分解を行って、「命令数 × 命令あたりの平均クロック サイクル数 (Cycles Per struct、CPI と呼ばれる)」に変換できます。命令が異なれば必要なサイクルも異なり、加算と乗算はどちらも 1 つの CPU 命令に対応しますが、乗算は加算よりも多くのサイクルを必要とするため、当然遅くなります。このように分割した後、プログラムの CPU 実行時間は、これら 3 つの部分の積になる可能性があります。
プログラムの CPU 実行時間 = 命令数 × CPI × クロック サイクル タイム
したがって、パフォーマンスの問題を解決したい場合は、実際には 3 つすべてを最適化する必要があります。
クロック サイクル タイムはコンピュータの主な周波数であり、コンピュータ ハードウェアによって異なります。有名なムーアの法則により、コンピューターの主周波数が継続的に増加しています。例えば、最初に使っていた80386のメイン周波数は33MHzしかありませんでしたが、今手元にあるノートパソコンは2.8GHzとメイン周波数は100倍近くになっています。
命令あたりの平均クロック サイクル数 (CPI) は、命令に必要な CPU サイクルの数です。後で CPU の構造を説明するときに、最新の CPU がパイプライン テクノロジ (Pipeline) を使用して、命令に必要な CPU サイクルをできるだけ少なくしていることがわかります。したがって、CPI の最適化もコンピュータの構成とアーキテクチャの重要な部分です。
命令数は、プログラムを実行するために必要な命令の数と、どの命令が使用されるかを表します。多くの場合、この問題はコンパイラに委ねられます。同じコードがコンピュータ命令にコンパイルされると、さまざまな表現が得られます。