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

多くのノードで問題の完了まで実行すると、長い時間がかかります。MP LINPACK の検索空間も巨大です。実行する問題のサイズのみでなく、ブロックサイズの数、グリッドレイアウト、ステップの先読み、異なる因数分解方法の使用なども影響します。以前に得られた最良のパフォーマンスよりも、0.01% 遅くなったことを発見するためだけに大きな問題を最後まで実行しても、膨大な時間の浪費になります。

検索時間を短縮するには以下のオプションを使用します。

以前の HPL に戻すには、これらのオプションを定義せずに最初から再コンパイルします ("make arch=<arch> clean_arch_all" を実行してください)。

-DASYOUGO

-DASYOUGO は、実行の進行に伴い、パフォーマンス・データを提供します。 LU 分解 (行列を下 (L) 三角行列と上 (U) 三角行列の積に分解すること) が発生するため、パフォーマンスは常に開始時は高く、徐々に低くなります。ASYOUGO パフォーマンス評価は通常 (LU 分解により遅くなるため) 高めに評価されますが、問題が進行するにつれて、より正確になります。 ステップの先読みが多いほど、最初の数は正確でなくなります。 ASYOUGO は MP LINPACK が実行する LU 分解を含めて評価しようとするため、実際に達成された DGEMM パフォーマンスを測定する ASYOUGO2 と比較して高めに評価されます。 ASYOUGO の出力は ASYOUGO2 が提供する情報のサブセットであることに注意してください。 このため、出力の詳細は、-DASYOUGO2 オプションの説明を参照してください。

-DENDEARLY

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

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

-DASYOUGO2

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

次に、ASYOUGO2 出力のサンプルを示します (最初の 3 つの非侵入数は ASYOUGO および ENDEARLY の説明を参照してください)。

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

問題サイズは N=16000 で、ブロックサイズは 128 でした。10 ブロック、つまり 1280 列を処理した後、出力は画面に送られました。ここで、完了した列の小数は 1280/16000=0.08 です。行列分解により、最大 40 の出力結果がさまざまな場所に出力されます: fractions
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 が見つかりました。非常に大きな問題では、小数の数はより正確になります。上記において、112 を超える数が出力されることはありません。このため、アップデートの数はより小さな問題では 112 よりも少なく、より大きな問題では正確に 112 になります。

Mflops は、LU 分解が完了した 1280 列に基づく評価です。 しかし、ステップの先読みが行われると、出力が行われるときに作業が実際に完了していない場合があります。しかし、これは同一の実行を比較するためには良い評価です。

括弧で囲まれている 3 つの数は、侵入型 ASYOUGO2 のアドインです。 DT は、プロセッサー 0 が DGEMM で費やした合計時間 (単位は秒) です。 DF は、1 つのプロセッサーによって DGEMM で実行された処理の数 (単位は 10 億) です。 したがって、プロセッサー 0 の DGEMM でのパフォーマンス (Gflops) は常に DF/DT になります。 LU flops の数の代わりに DGEMM flops の数を基本として使用し、DMF を調べることで、実行のパフォーマンスの下限がわかります (Mflops はグローバル LU 時間を使用しますが、HPL のノード (0,0) のみは任意の出力を返すため、DGEMM flops は問題がノード間で平等に分散されているという仮定の下で計算されます)。

上記のパフォーマンス監視ツールを使用して異なる HPL.dat 入力データセットを比較する場合、LU を使用したときのパフォーマンス低下のパターンは、一部の入力データの影響を受けやすいことに注意してください。 例えば、非常に小さな問題を実行した場合、初期値から終了値までのパフォーマンス低下は非常に急速です。より大きな問題では、パフォーマンス低下はゆるやかになるため、最初のいくつかのパフォーマンス値を使用して問題サイズの違い (例えば、7000000 と 701000) を評価しても安全です。パフォーマンス低下に影響を与える別の要因は、グリッドの次元 (P および Q) です。大きな問題では、P と Q が値でほぼ等しい場合、最初の数ステップからのパフォーマンス低下が少なくなる傾向があります。ブロードキャスト型のような大量のパラメーターを利用するように変更することで、最終的なパフォーマンスに非常に近いパフォーマンスを最初の数ステップで特定することができます。

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

関連情報


このヘルプトピックについてのフィードバックを送信

© 2006 - 2010 Intel Corporation. 無断での引用、転載を禁じます。