opi-clst HPLでベンチマーク パラメータ探索編

 2016-11-25
HPLが動く環境が出来たので、イイカンジのスコアが出せるパラメータを探ってみます。
 
HPLは動作時のパラメータをHPL.datというファイルから読み取って動作します。
このHPL.datに環境にマッチした条件を設定する事で無駄な計算コストを省いてスコアを伸ばす事が出来ます。
ただし、柔軟に設定できるため最適条件を探すのは結構大変です。



忙しい人のための結論

  • HPLの動作環境を確認した前回は参考文献からのパラメータを用いて4.050GFLOPSでした。
  • チューニングにより、ATLAS版CBLASをlinkしたHPLでのベストスコアは5.248GFLOPSとなりました。
  • パラメータを振ってみたが局所解に捕らわれがちになるためチューニングは難しい。
  • 5.2GFLOPSはFUJITSU VP2000(5GFLOPS 1988年)にやや勝っており、28年前のスーパーコンピュータになんとか勝利しました。(´・ω・`)
  • まだあきらめません!




参考文献

HPL Tuning
http://www.netlib.org/benchmark/hpl/tuning.html

HPL Frequently Asked Questions
http://www.netlib.org/benchmark/hpl/faqs.html

How do I tune my HPL.dat file?
http://www.advancedclustering.com/act-kb/tune-hpl-dat-file/





チューニングのための情報

HPL.datをジェネレートしてくれるサイトがあったのでそこの出力結果も参考になります。

HPLのチューニングのページにガイドラインがあり推奨設定について触れられている。

If these nodes are multi-processors, a row-major mapping is recommended.

HPL likes "square" or slightly flat process grids.

Broadcast parameters: at this time it is far from obvious to me what the best setting is,
so i would probably try them all.



さらに、HPLのFAQも参考になる。

What problem size N should I run ?
...(snip)...So for example, if you have 4 nodes with 256 Mb of memory on each,
this corresponds to 1 Gb total, i.e., 125 M double precision (8 bytes) elements.
The square root of that number is 11585. One definitely needs to leave some memory for
the OS as well as for other things, so a problem size of 10000 is likely to fit.
As a rule of thumb, 80 % of the total amount of memory is a good guess....(snip)..

What block size NB should I use ?
...(snip)...The best values depend on the computation / communication performance ratio of
your system.
To a much less extent, the problem size matters as well. Say for example,
you emperically found that 44 was a good block size with respect to performance.
88 or 132 are likely to give slightly better results for large problem sizes because of
a slighlty higher flop rate.

What process grid ratio P x Q should I use ?
...(snip)... On such a network, the performance and scalability of HPL is strongly limited
and very flat process grids are likely to be the best choices: 1 x 4, 1 x 8, 2 x 4 ...





パラメータ探索の方針

これら参考情報からまとめると・・・
  • マルチプロセッサー環境ではRow-major mappingが良いらしい。
  • P:Q比率は正方形に近い方が良いらしい。
    • メッシュネットワークであればP:Qが1:1から1:3程度までが推奨らしい
    • 通常の(?)フラットなethernetなら1:4、1:8、1:2程度を推奨らしい
    • 今回はメッシュネットワークではないので、56並列時は7:8ではなく、4:14とかのほうがいいのかな?
  • BCASTメソッドはとりあえず全部試してみるべきらしい
  • Nの値はメモリによって決まるらしい
    • clst-NODEのOrangePi PCは1GBのRAMを持ち、14nodeあるので、メモリの総量は14GBになる。
    • 14GBは1750M [double precision elements]に相当するので、平方根をとると41833になる。
    • 経験的にメモリ量の80%程度が良いらしいので、N=33466がFAQで示唆される指標で算出される。
    • この値はジェネレータにメモリ量の80%を入力した際の出力に近い。
      • どうやらジェネレータはNBで割り切れる最大のNsを出力しているようだ。
  • NBの値はネットワーク性能、IO性能によって決まる
    • 1ボードPCはI/Oが遅いので頻繁にネットワークで通信されるとスコアが落ちてしまうと思われる。
    • NBサイズは32~256の値にしておくのが得策だとFAQは言うので、最大値である256がいいのかな?
    • ジェネレータではこの値はこちらから入力する必要があり、192がデフォルト値だった。
    • ハードウェアの事情を考慮して256よりも若干増やす?




パラメータを振って確認

4.050GFLOPSを出したHPL.dat(青字で表記)をベースにいくつか変更してスコア(GFLOPS)を確認してみた結果、以下の傾向が見られた。
  • Nは大きいほどスコアが良い
  • Nは大きすぎるとHPLが異常終了する
    • swapを殆ど用意していないため、メモリ不足で落ちている?
  • NBはNの値に依存して最適値が変わる
    • N=25600,NB=32付近の結果を見ると、Nが大きいとNBも大きくするという関係でもないようだが・・
  • P<=Qの条件ではRow-majorもColmn-majorも有意差ナシ
  • P>=Qの条件ではColmn-majorのほうがスコアが良い
    • ガイドラインではマルチプロセッサー環境ではRow-majorが推奨されていたがこれはいわゆるマルチコア時のことであり、1コア/1ノードの場合は該当しないのかも
    • ネットで検索するとP<=Qで設定せよとする文献が多いのだが、HPLガイドラインではstay away from the 1-by-Q and P-by-1 process grids.等の記述もあり、必ずしもP<=Qを守る必要はないらしい
  • PFACT,RFACTはどの組み合わせでも有意差ナシ
  • BCASTはLnMのスコアが良い
    • ネットワークのIOが遅いのでロングメッセージ方式のほうが有利ということだろうか。
  • コンパイル時の最適化オプション有意差ナシ
    • 主な計算はlibblasでやってるからと想像



N=6400N=12800N=25600N=28800N=32000N=33280N=34816N=38400
(time)70s350s2700s3400s4400s4800s5500sn/a
NB=81.7482.7763.4213.5173.5583.5683.619FAILED
NB=161.9913.2674.0234.2914.4284.4874.533FAILED
NB=322.2633.7564.3724.6904.9265.0305.167FAILED
NB=642.5703.9474.3104.6894.8785.1045.138FAILED
NB=962.8714.3004.0504.3824.8814.7524.957FAILED
NB=1282.8414.2864.0894.3594.9284.888FAILEDFAILED
NB=1602.9254.4103.8594.4375.0214.760FAILEDFAILED
NB=1922.9824.4605.1025.1415.1215.145FAILEDFAILED
NB=2242.7824.3155.0305.0624.9865.168FAILEDFAILED
NB=2562.7644.3425.1785.2155.0425.164FAILEDFAILED
NB=2882.7434.2764.9735.2195.0835.005FAILEDFAILED
NB=3202.7254.2434.9925.1814.932FAILEDFAILEDFAILED
NB=3842.6124.1164.8875.1114.927FAILEDFAILEDFAILED
NB=4482.4423.9304.9044.9734.763FAILEDFAILEDFAILED
NB=5122.3223.8064.8414.759FAILEDFAILEDFAILEDFAILED
FAILEDの表示は、HPLが異常終了したものです。swapを128MBしか取っていない(armbianデフォルト)ため、おそらくメモリ不足で落ちていると思われます。

P:Q=2:7P:Q=1:14P:Q=7:2P:Q=14:1
Row-major4.0503.2714.1123.048
Column-major3.9853.3204.4693.087


PFACT=0PFACT=1PFACT=2
LeftCroutRight
RFACT=0Left3.9993.9513.962
RFACT=1Crout4.0083.9964.050
RFACT=2Right4.0174.0583.960


BCAST=0BCAST=1BCAST=2BCAST=3BCAST=4BCAST=5
1rg1rM2rg2rMLngLnM
-3.9694.0504.0724.2024.2174.455


--marm -mfpu=vfpv4
-mfloat-abi=hard
-march=armv7-a
-4.0503.985




有望そうな範囲をさらに探索

とりあえずでいろいろパラメータを振ってみた結果から、有望そうなパラメータを下記に絞ってみた。
  • N=28800
  • NB=192,224,256,288,320,384
    • N,NBはBCASTによって影響をうける可能性高いため広めに探索する。
  • P:Q=2:7(Row-major),7:2(Column-major)
    • 前回の結果の上位2つの組み合わせを試す。
  • BCAST=0,1,2,3,4,5
    • BCASTはガイドラインにあった様に全探索する。ただしおそらくLnM(BCAST=5)が有望。
  • PFACT=2,RFACT=1
    • 前回の結果から特に有意差無いためデフォルト値をそのまま使う。

P:Q,major2:7,Row-major7:2,Colmn-major
BCAST012345012345
NNB
288001925.0075.1415.0355.1124.4724.1674.4604.4664.4504.4584.2364.220
2245.1665.0645.1695.0464.4604.6614.4114.4184.4134.4084.1754.158
2564.9545.2155.0815.0074.4114.5994.414-----
2884.9645.2194.9915.1294.3024.678------
3205.2485.1815.1555.1834.3894.690------
3844.9665.1115.1385.0124.2424.558------
ハイフン表示の箇所はデータ取るのをあきらめた箇所です(´・ω・`)



結果は5.248GFLOPS

ベストスコアは5.248GFLOPSとなった。
その際の条件は下記。
  • N=28800
  • NB=320
  • BCAST=0(1ring)
  • P:Q(major)=2:7(Row-major)

各パラメータを振ってみた結果、どうやらN,NBの最適値と、BCAST、P:Q比のそれぞれの最適値を組み合わせても、必ずしもそれが最適値になるとは限らないということが分かった。
個別にパラメータを振っても局所解にしかたどり着けないらしい。困ったね。まぁこのくらいが妥協点だろうか。

N-NB.png
N-NB-heatmap.png
パラメータ振りの結果をグラフ化してみると、おおよそ5GFLOPS付近になんらかの壁があることが予想される。
OrangePi PC 14台でのクラスタで、ATLAS版CBLASなHPLではこれくらいか。。。


5.2GFLOPSってどんなもん?

下記のhardware-naviによると、5.2GFLOPSに該当するのは Pentium 4 HT 2.6C 等があるらしい。

http://hardware-navi.com/cpu/?Company=&Brand=&iGPU=&Socket=&Architecture=&nos=all&Order=GFLOPS&Type=&Cores=&qsv=&TDP=&CodeName=&noscore=hidden&logo=



検索してみると、Pentium 4 HT 2.6C は2003年発売、発売当時2.8万円前後とのこと。

【 2003年5月17日号 】FSB 800MHz対応Pentium 4の2.4C/2.6C/2.8C GHzが発売に
低価格なFSB 800MHz対応モデル、最安の2.4C GHzは品薄
http://akiba-pc.watch.impress.co.jp/hotline/20030517/fsb800p4.html



opi-clst n14の最低限必要な製作費をザックリとリストアップしてみると下記のように約5.6万円になる。
品名単価個数費用
OrangePi PC$1514$210
RaspberryPi2B$421$42
放熱器¥5018¥900
熱伝導両面テープ¥802¥160
microSDカード(16GB)¥68015¥10,200
LANケーブル(0.5M)¥28017¥4,760
RWS100B-5¥3,8002¥7,600
冷却用FAN¥1,0002¥2,000
LANスイッチングハブ¥1,4003¥4,200
合計¥56,280

Pentium4のCPUを買って激安のメモリやマザボ、電源を揃えると5.6万円は超えそうなので、opi-clst n14の勝利!!やった!!

ただし、12年前のCPUですけどね・・・・・

負け。。。

でも、まだ勝てる見込みあります。スコア向上の見込みはまだまだまだまだあります。  


あきらめません

これが限界というわけではありません。
ATLASはマルチスレッドに対応していないので現状では1ノードあたり1コアしか使っていないのです。
OrangePi PCは4コアのSoCを持っていますからね。まだスコアを伸ばす余地はあります。
今後、1ノードに4ジョブ割り付けや、マルチスレッドに対応しているOpenBLAS導入を試してみる予定です!

 

 
コメント












管理者にだけ表示を許可する
トラックバック
トラックバックURL:
http://wbbwbb.blog83.fc2.com/tb.php/273-8014855c
≪ トップページへこのページの先頭へ  ≫