多くのノードで問題の完了まで実行すると、長い時間がかかります。Intel® Optimized LINPACK Benchmark の検索空間も巨大です。問題サイズ、ブロックサイズ、グリッドレイアウト、ステップの先読み、因数分解方法など、いくつかのパラメーターを変更してパフォーマンスを向上できます。以前に得られた最良のパフォーマンスよりも、0.01% 遅くなったことを発見するためだけに大きな問題を最後まで実行しても、あまり意味がありません。
限界パフォーマンスに影響を与えるため、-DASYOUGO2 は慎重に使用してください。 DGEMM の内部パフォーマンスを参照するには、-DASYOUGO2 および -DASYOUGO2_DISPLAY を使用してコンパイルします。 これらのオプションを使用することでパフォーマンスは約 0.2% 損なわれますが、有用な DGEMM 情報が提供されます。
オリジナルの HPL に戻すには、これらのオプションを定義せずに最初から再コンパイルします ("make arch=<arch> clean_arch_all" を実行してください)。
-DASYOUGO は、実行の進行に伴い、パフォーマンス・データを提供します。LU 分解は問題が進行するにつれて遅くなるため、パフォーマンスは常に開始時は高く、徐々に低くなります。ASYOUGO パフォーマンス評価は通常高めに評価されますが、問題が進行するにつれて、より正確になります。 ステップの先読みが多いほど、最初の数は正確でなくなります。ASYOUGO は Intel® Optimized LINPACK Benchmark が実行する LU 分解を含めて評価しようとするため、実際に達成された DGEMM パフォーマンスを測定する ASYOUGO2 と比較して高めに評価されます。 ASYOUGO の出力は ASYOUGO2 が提供する情報のサブセットであることに注意してください。 このため、出力の詳細は、-DASYOUGO2 オプションの説明を参照してください。
-DENDEARLY は、いくつかのステップの後に問題を終了します。このため、モニターをせずに 10 から 20 程度の HPL をセットアップして実行し、最も速かった HPL のみを完了させることができます。 -DENDEARLY は -DASYOUGO を想定します。 両方を定義することができますが、その必要はありません。早く終了する問題の残差の確認を回避するため、ENDEARLY をテストする場合は、HPL.dat の threshold パラメーターを負の数に設定することを推奨します。 -DENDEARLY を使用する場合、-DASYOUGO2 を使用してコンパイルしたほうがより多くの情報が得られる場合もあります。
-DENDEARLY は、ブロックサイズで DGEMM の反復を数回行った後、問題を停止します (ブロックサイズが大きいほど、得られる情報も多くなります)。 5 または 6 のアップデートのみ出力します (-DASYOUGO は問題を完了する前に 46 程度の出力要素を出力します)。
-DASYOUGO と -DENDEARLY のパフォーマンスは常に 1 つの速度で開始され、ゆっくり増加した後、終了に向かって速度が落ちます (LU 分解の進行状況を反映しています)。 -DENDEARLY は通常、速度が落ちる前に終了します。
-DENDEARLY は、HPL エラーとともに問題を早く終了します。問題は完了していないため、見つからない (誤った) 残差を無視する必要があります。しかし、初期のパフォーマンスは確認できるため、許容できるパフォーマンスの場合は -DENDEARLY を指定しないで問題を最後まで実行します。 エラーチェックを回避するには、HPL.dat に含まれている threshold パラメーターを負の数にしてください。
-DENDEARLY は早く終了するため、HPL は問題が完了したと解釈し、問題が完了したものとして GFLOP 評価を計算します。 この誤った高い評価は無視してください。
より大きな問題では、精度はより高くなります。-DENDEARLY が返す最後のアップデートは、問題を完了まで実行したときのアップデートに近くなります。 -DENDEARLY は、小さな問題では近似が不十分です。 この理由により、ENDEARLY は ASYOUGO2 と組み合わせて使用すべきです。ASYOUGO2 は実際の DGEMM パフォーマンスを報告するため、開始した問題への近似がより近くなります。
-DASYOUGO2 は、詳細な単一ノードの DGEMM パフォーマンス情報を提供します。 すべての DGEMM 呼び出しをキャプチャーして (Fortran BLAS を使用している場合)、データを記録します。 このため、ルーチンにはパフォーマンス・オーバーヘッドが存在します。パフォーマンスに影響しない -DASYOUGO とは異なり、-DASYOUGO2 は、パフォーマンスをモニターするため、DGEMM の呼び出しごとに中断します。 たとえパフォーマンスへの影響が 0.2% 未満であっても、大きな問題ではこのオーバーヘッドに注意する必要があります。
Col=001280 Fract=0.050 Mflops=42454.99 (DT=9.5 DF=34.1 DMF=38322.78)
Col、Fract、Mflops の値は、ASYOUGO と ENDEARLY でも生成されます。
この例で、問題サイズは 16000、ブロックサイズは 128 です。10 ブロック (または 1280 列 (Col)) を処理した後、出力が画面に送られました。ここで、完了した列の割合 (Fract) は 1280/16000=0.08 です。行列分解のさまざまな場所で、最大 111 個の数値が出力されます:
0.005 0.010 0.015 0.020 0.025 0.030 0.035 0.040 0.045 0.050 0.055 0.060 0.065 0.070 0.075 0.080 0.085 0.090 0.095 0.100 0.105 0.110 0.115 0.120 0.125 0.130 0.135 0.140 0.145 0.150 0.155 0.160 0.165 0.170 0.175 0.180 0.185 0.190 0.195 0.200 0.205 0.210 0.215 0.220 0.225 0.230 0.235 0.240 0.245 0.250 0.255 0.260 0.265 0.270 0.275 0.280 0.285 0.290 0.295 0.300 0.305 0.310 0.315 0.320 0.325 0.330 0.335 0.340 0.345 0.350 0.355 0.360 0.365 0.370 0.375 0.380 0.385 0.390 0.395 0.400 0.405 0.410 0.415 0.420 0.425 0.430 0.435 0.440 0.445 0.450 0.455 0.460 0.465 0.470 0.475 0.480 0.485 0.490 0.495 0.515 0.535 0.555 0.575 0.595 0.615 0.635 0.655 0.675 0.695 0.795 0.895。
しかし、ここでは問題サイズが非常に小さく、それに比べてブロック数が非常に大きいため、0.045 の値を出力するとすぐに、列の割合である 0.08 に達してしまいました。非常に大きな問題では、割合がより正確になります。
上記において、-DASYOUGO2 が 112 個を超える数値を出力することはありません。このため、アップデートの数は、より小さな問題では 112 よりも少なく、最も大きな問題では正確に 112 になります。
Mflops は、LU 分解が完了した列数に基づく評価です。しかし、ステップの先読みが行われると、出力が行われるときに作業が実際に完了していない場合があります。しかし、これは同一の実行を比較するためには良い評価です。
括弧内の 3 つの数値は、パフォーマンスに影響する ASYOUGO2 のアドインです。 DT は、プロセッサー 0 が DGEMM で費やした合計時間です。 DF は、1 つのプロセッサーによって DGEMM で実行された処理の数 (単位は 10 億) です。 したがって、プロセッサー 0 の DGEMM でのパフォーマンス (GFLOPs) は常に DF/DT になります。 LU FLOPs の数の代わりに DGEMM FLOPs の数を基本として使用し、DMF を調べて上記の Mflops と比較することで、実行のパフォーマンスの下限が分かります
このセクションで説明したパフォーマンス監視ツールを使用して異なる HPL.dat 入力データセットを比較する場合、LU を使用したときのパフォーマンス低下のパターンは、入力データのサイズに影響を受けやすいことに注意してください。 例えば、非常に小さな問題を実行した場合、初期値から終了値までのパフォーマンス低下は非常に急速です。より大きな問題では、パフォーマンス低下はゆるやかになるため、最初のいくつかのパフォーマンス値を使用して問題サイズの違い (例えば、7000000 と 701000) を評価しても安全です。パフォーマンス低下に影響を与える別の要因は、グリッドの次元の関係 (P および Q) です。 大きな問題では、P と Q がほぼ等しい場合、最初の数ステップからのパフォーマンス低下が少なくなる傾向があります。 ブロードキャスト型のような大量のパラメーターを利用するように変更することで、最終的なパフォーマンスに非常に近いパフォーマンスを最初の数ステップで特定することができます。