電子計算記

個人的な検証を

14. MPIクラスターを作ろう! - qn24bを動かしてみる

前回からのつづきです。
13. MPIクラスターを作ろう! - 姫野ベンチをもう少し動かしてみる - 電子計算記

前回までの姫野ベンチはちょっと難しかったので、もっと簡単にノードを増やすとスケールするのがわかるようなベンチマークを動かしてみましょう。

ということで、今回はqn24bです。Nクイーン問題が何かはリンク先をどうぞ。
N-queens

あまりメジャーじゃないかもしれませんが、私は10年以上前から愛用しています。というのも

・コードがシンプルでわかりやすい
・逐次版、OpenMP版、MPI版といろいろな実装がある
OpenMP版は単純な分割による並列化、MPI版はMaster-Worker型による並列化と様々な実装がとれる
・並列化後のプロセス/スレッド間のデータのやりとりがほぼないので、スケールしやすい
→ということで、並列分散プログラミングの勉強には最適な題材なのです。
 新しい並列計算環境がでてきたら、まずはこのqn24bをポーティングしたりもしてます。

ベンチマークソフトとしても特徴的で、この手のベンチマークツールは浮動小数点演算の処理性能を計測するものが多い中、qn24bは整数演算が主なのです。

では早速はじめていきましょう。

mpiuser@compute-1:~$ wget http://www.arch.cs.titech.ac.jp/~kise/nq/package/qn24b-version1.0.tgz
mpiuser@compute-1:~$ mkdir /nfs/qn24b
mpiuser@compute-1:~$ tar zxf qn24b-version1.0.tgz -C /nfs/qn24b
mpiuser@compute-1:~$ cd /nfs/qn24b/version1.0/mpi/

次にmakeしたいところですが、1点修正が必要です。
Makefileの9行目の-staticオプションを削除してください。
mpicc -Wall -O2 $(SRC) -o $(TRG)
あとはmakeするだけです。

mpiuser@compute-1:/nfs/qn24b/version1.0/mpi$ make

実行は、問題サイズ(Nクイーン問題のNの部分)を入れるのが必要になります。このNの値が大きいほど、計算量も大きくなり時間がかかります。
例えば16クイーン問題を4プロセスで動かすときは以下になります。

mpiuser@compute-1:/nfs/qn24b/version1.0/mpi$ mpirun -np 4 --hostfile ~/my_hosts ./qn24b_mpi 16
〜省略〜
003 : 09839 09844 0000000000001050 099.95 00000.00 Tue Jan  9 00:02:14 2018
002 : 09841 09844 0000000000000944 099.96 00000.00 Tue Jan  9 00:02:14 2018
001 : 09840 09844 0000000000001160 099.97 00000.00 Tue Jan  9 00:02:14 2018
003 : 09842 09844 0000000000000994 099.98 00000.00 Tue Jan  9 00:02:14 2018
002 : 09843 09844 0000000000000878 099.99 00000.00 Tue Jan  9 00:02:14 2018
001 : 09844 09844 0000000000000650 100.00 00000.00 Tue Jan  9 00:02:14 2018
=============================================
qn24b MPI version 1.0.0 2004-06-16
problem size n        : 16
total   solutions     : 14772512
correct solutions     : 14772512
million solutions/sec : 6.018
elapsed time (sec)    : 2.455
=============================================

total solutionsとcorrect solutions が一致していれば計算処理は成功です。
ベンチマークのスコアとして秒あたりの処理数であるmillion solutions/sec(値が大きいほど高速)か、処理時間のelapsed time (sec)(値が小さいほど高速)にあたります。
このとき、Master-Worker型で動くので実際に計算処理しているのは4プロセス中3プロセスということになります。

では、Light.S1とHighCPU.M4をそれぞれ16台づつ並べた結果をグラフ化してみましょう。

f:id:fujish:20180109010640p:plain
f:id:fujish:20180109010821p:plain

基本的にはノード数(プロセス数)に応じてスコアがあがっていくのがわかると思います。
その中でいくつか気になる点が出てきます。

1) N=15のプロセス数に応じた伸びが悪い
Light.S1もHighCPU.M4も同じ傾向にあると思いますがこれは問題規模が小さすぎるせいです。
Nはある程度大きくしないとですが、N=24とか多きすぎると現実的な時間で処理しきれません。

2) Light.S1のN=16のnp4以上やN=17のnp16のときの値がやけに高速
処理時間が2-3秒以下だとクロックキャッピングがかかる前に処理が終わるため高速になります。HighCPU.M4に近い値になってます。

ということで、ここでもクロックキャッピングの影響が見えました。一方で並列化の処理方式上、前回までの姫野ベンチと違って綺麗にスケールしていくことが見えました。
次回はいよいよスパコンベンチマークの定番HPLをやっていきましょう。

fujish.hateblo.jp