検索時間を短縮するためのオプション

-DASYOUGO

-DASYOUGO は、実行中のパフォーマンス・データをレポートします。LU 分解は問題が進行するにつれて遅くなるため、パフォーマンスは常に開始時は高く、徐々に低くなります。-DASYOUGO によるパフォーマンスの評価は通常高めにレポートされますが、問題の処理が進行するにつれて、より正確になります。 ステップの先読みが多いほど、初期の数は正確でなくなります。-DASYOUGO は Intel® Optimized LINPACK Benchmark が実行する LU 分解を含めて評価しようとするため、実際に達成された DGEMM パフォーマンスを測定する -DASYOUGO2 と比較して高めに評価されます。 -DASYOUGO の出力は -DASYOUGO2 がレポートする情報のサブセットであることに注意してください。 出力の詳細は、DASYOUGO2 オプションの説明を参照してください。

-DENDEARLY

-DENDEARLY は、いくつかのステップの後に問題を終了します。このため、モニターをせずに 10 から 20 程度の HPL をセットアップして実行し、最も速かった HPL のみを完了させることができます。-DENDEARLY は -DASYOUGO を仮定します。 両方を定義することもできますが、その必要はありません。早く終了する問題の残差の確認を回避するため、-DENDEARLY をテストする場合は、HPL.dat の threshold パラメーターを負の数に設定することを推奨します。 -DENDEARLY を使用する場合、-DASYOUGO2 を追加してコンパイルしたほうがより多くの情報が得られる場合もあります。

-DENDEARLY の使用に関する注意:

• -DENDEARLY は、ブロックサイズで DGEMM の反復を数回行った後、問題を停止します (ブロックサイズが大きいほど、得られる情報も多くなります)。 5 または 6 のアップデートのみ出力します (-DASYOUGO は問題を完了する前に 46 項目程度の情報を出力します)。

• -DASYOUGO と -DENDEARLY のパフォーマンスは常に一定の速度で開始され、ゆっくり増加した後、終了に向かって減速していきます (LU 分解の進行状況を反映)。 -DENDEARLY は通常、減速する前に終了します。

• -DENDEARLY は、HPL エラーとともに問題を早く終了します。問題は完了していないため、誤った残差を無視する必要があります。初期のパフォーマンスは確認できますが、許容できるパフォーマンスであれば -DENDEARLY を指定しないで問題を最後まで実行します。 エラーチェックを回避するには、HPL.dat の threshold パラメーターを負の数にしてください。

• -DENDEARLY は早く終了するため、HPL は問題が完了したと解釈し、問題が完了したものとして GFLOPS 評価を計算します。 この誤った高い評価は無視してください。

• より大きな問題では、精度はより高くなります。-DENDEARLY が返す最後のアップデートは、問題を完了まで実行したときのアップデートに近くなります。 -DENDEARLY は、小さな問題では近似が不十分です。 この理由により、-DENDEARLY は -DASYOUGO2 と組み合わせて使用すべきです。-DASYOUGO2 は実際の DGEMM パフォーマンスを報告するため、問題への近似がより近くなります。

-DASYOUGO2

-DASYOUGO2 は、詳細な単一ノードの DGEMM パフォーマンス情報をレポートします。 すべての DGEMM 呼び出しをキャプチャーして (Fortran BLAS を使用している場合)、データを記録します。 このため、ルーチンにはパフォーマンス・オーバーヘッドがあります。パフォーマンスに影響しない -DASYOUGO とは異なり、-DASYOUGO2 はパフォーマンスをモニターするため、DGEMM の呼び出しごとに中断します。 たとえパフォーマンスへの影響が 0.1% 未満であっても、大きな問題ではこのオーバーヘッドに注意する必要があります。

次に、-DASYOUGO2 出力のサンプルを示します。

Col=001280 Fract=0.050 Mflops=42454.99 (DT=9.5 DF=34.1 DMF=38322.78)

この例で、問題サイズは 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 つの数値は、パフォーマンスに影響する -DASYOUGO2 のアドインです。 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 がほぼ等しい場合、最初の数ステップからのパフォーマンス低下が少なくなる傾向があります。 ブロードキャスト型のような大量のパラメーターを利用するように変更することで、最終的なパフォーマンスに非常に近いパフォーマンスを最初の数ステップで特定することができます。

これらのツールを使用すると、さまざまな量のデータをテストすることが可能です。