スポンサーサイト

 --------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
カテゴリ :スポンサー広告 トラックバック(-) コメント(-)

opi-clst HPLでベンチマーク 56並列の威力を見よ!編

 2016-11-26
前々回はHPLの動作環境を立ち上げ前回はHPLの最適パラメータ探索を楽しみました。
今回は・・・本命の全コア総動員した56並列でのパワーを確認します!
 
これまでのHPLのスコアは1コアしか使っていませんでした。cactiのグラフでもロードアベレージが1.2程度までしか上がっていないのが分かります。
opiclst-n14-la12.png
これはHPLで使用しているATLASがマルチスレッドに対応していないため、1つのノードに1つのジョブを割り当てたとき、1コアしか使用しないためです。
OrangePi PCは4coreのSoCを搭載しているので、コアを全部使うようにジョブを割り振ってHPLを回してみましょう。



忙しい人のための結論

ATLAS版CBLAS(シングルスレッド)をlinkしたHPLで、SoCのコアを全て使い切ろうとコアの数だけMPIのジョブを割り振った結果、1コア実行の時よりもスコアが悪くなりました。
ネットワークIOが遅いため、通信にかかるペナルティが多くてスコアを落としたと思われます。
むやみに並列数を上げるとオーバーヘッドで処理速度が落ちるという例のアレに陥ったというワケですね。残念。



パラメータ探索

まずは1コア動作時の結果を参考にしてパラメータを振っていこうと思います。
4コア動作時の相違点として大きいのは、Nが各プロセスの使用可能なRAMサイズに依存するとのことなので、4core動作させる場合は、1GBのRAMを4分割してそれぞれで使うことになる。つまり1core動作時の1/4程度しか適用できないという点。Nが大きいとスコアに好影響なため、小さくせざるを得ないのは厳しい。

まずは暫定の条件を下記に定めてパラメタ振りした。
  • N=7500
    • 1coreではN=300000前後までは動作することから、N=20000/4=7500 これはRAMサイズによって明確に上限が決まってしまう
  • NB=75,100,150
    • 1core時の最適条件だったN:NB=28800:288=100:1より、N=7500の場合NB=75が算出されるがNICが重いので150(=75*2)まで試したい
  • BCAST=0,1,2,3,4,5
    • ガイドラインにて全探索推奨のため
  • P:Q=4:14(Row),7:8(Row),14:4(Colmn),8:7(Colmn)
    • 試行で傾向が掴みにくかったため広めに探索
    • 4:14(Row)が有望
  • PFACT=2,RFACT=1
    • 試行結果で特に有意差無いためデフォルト値をそのまま使う


P:Q,major4:14,Row-major7:8,Row-major
BCAST012345012345
NNB
7500754.0263.7563.4713.4432.5202.3911.6131.6381.5621.5591.2471.312
1004.3034.0233.7293.6792.9242.6881.6441.6611.5891.5731.3981.464
1503.7573.6293.4323.4122.7742.6641.7021.7391.6601.5911.5131.616


P:Q,major14:4,Colmn-major8:7,Colmn-major
BCAST012345012345
NNB
7500751.3861.3541.2771.3351.2161.2191.5381.5091.5051.5210.97291.158
1001.4901.4731.4351.4631.3721.3711.5721.5641.5561.5751.1451.317
1501.6491.6131.5981.6241.4931.4771.5771.6131.5981.5881.2761.448


下記の傾向が見える。
  • N=7500のとき、最もスコアが良いのはNB=100
  • P>Q,Colmn-majorはスコアが悪い
  • BCASTで最もスコアが良いのはBCAST=0(1ring)
    • 1ringはバケツリレー的に通信をする
    • 54並列だとバケツリレー的に順番に通信した方がペナルティが少ないのだろうか?



期待に反して、4コア動作では遅くなってしまった。ネットワークのペナルティが効いているのだと思われる。
ロードアベレージも4まで上がって4コア使用するようにはなっているのだが。。。うーん。。
opiclst-n14-la4.png



ジョブの割り付け順によって改善できないだろうか?

cactiのグラフを見ると、ネットワーク負荷がかなり高いことがわかる。
ただでさえネットワークのIOが遅いというのに、もしかして・・・ 14ノードあるので100Mbpsの帯域を食いつぶしているのでは?
opiclst-n14-net.png

下記の仮説の元、再度パラメタ振りに挑戦!
  • mpi実行時に各IPの後ろにコア数を書き加えたら早くならないか?
    • コア数を書いておくとmpiはコア数を考慮して順番にジョブを割り当てる
    • 4つ毎に連番のジョブが1nodeに割り付けられるのでは?
    • BCAST=0(1ring)だと順番に通信していくので、node内の通信は早くなる
    • バケツリレーだと仮定すると、コア数付与しない均等割り付け時の1/4の通信量になるのではないか?
      • 4連続したジョブの両端が外部とのバケツリレーを行うため。


P:Q,major4:14,Row-major
BCAST012345
NNB
7500753.1132.9772.8832.7941.9782.174
1003.3863.1753.2873.1662.4562.733
1503.4503.3013.3233.3422.6903.045


遅い(´・ω・`)


一応ネットワークの使用帯域は減っているが、スコアは伸びず。
opi-clst-n14-net2.png
もっと別のボトルネックがあるのか。



結論

4コア動作(54並列実行)時のベストスコアは下記条件の時の4.303GFLOPSでした。
  • N=7500
  • NB=100
  • BCAST=0(1ring)
  • P:Q=4:14(Row)

1コア動作(14並列実行)時のベストスコアが ネットワークのIOが遅いためか? 4core * 14node = 54並列で実行したら、14並列(1core * 14node)の結果よりも悪くなった。

残念。
でもまだOpenBLASという望みがある(というかコレが大本命!ほんとです!)のでまだあきらめないぞ!
 
 
コメント












管理者にだけ表示を許可する
トラックバック
トラックバックURL:
http://wbbwbb.blog83.fc2.com/tb.php/274-0d4e7cfa
≪ トップページへこのページの先頭へ  ≫
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。