提出日：2014年 8月 4日

並列計算

課題 2

T2C_ ( Twitter : @T2C_)

1

■課題内容

課題 1で性能を分析したマルチスレッドのプログラムを利用し、

今回作成した MPIのプログラムで並列度を変えて実行させ、

並列度と実行時間の比較をし、考察を加える。

■ソースコードの作成、転送、コンパイル、実行

プリントに記載されているソースコードに時間計測用のコードを付加し、WinSCPで転送し、

今回は MPIを使用しているため、コマンド mpifccpx –o test10-3-2 –Kfast test10-3-2.c

を打ち込みコンパイルを行った。

以下に実際の C、それからジョブスクリプトのソースコードを記載する。

――――― 以下 ソースコード（C） ―――――

#include<stdio.h>

#include<math.h>

#include<mpi.h>

int main(int argc, char *argv[])

{

long n,i;

int myid, numprocs;

double mypi, pi, h, sum, x;

double time1=0, time2=0;

MPI_Init(&argc, &argv);

MPI_Comm_size(MPI_COMM_WORLD, &numprocs);

MPI_Comm_rank(MPI_COMM_WORLD, &myid);

n=100000000;

h=1.0/(double)n;

sum=0.0;

MPI_Barrier(MPI_COMM_WORLD);

time1= MPI_Wtime();

2

for(i=myid ;i <n ; i += numprocs)

{

x = h*((double)i+0.5);

sum += (4.0/(1.0+x*x));

}

MPI_Barrier(MPI_COMM_WORLD);

time2= MPI_Wtime();

mypi = h*sum;

MPI_Reduce(&mypi, &pi, 1, MPI_DOUBLE,MPI_SUM, 0, MPI_COMM_WORLD);

if(myid==0)

{

printf("pi is approximately %.16f \n",pi);

printf("time= %lf",(time2-time1));

}

MPI_Finalize();

}

――――― ソースコード（C）ここまで ―――――

――――― 以下 ソースコード（ジョブスクリプト） ―――――

#!/bin/bash

#------ pjsub option ------#

#PJM -L "rscgrp=debug"

#PJM -L "node=1"

#PJM --mpi "proc=1"

#PJM -L "elapse =1:00"

#PJM -j

#------ Program execution ------#

mpiexec ./test10-3-2

――――― ソースコード（ジョブスクリプト）ここまで ―――――

3

■実行結果

pi is approximately 3.1415926535904264

time= 2.097642

と出力された。下は並列化した部分の実行時間である（単位：秒）。

■プロセス数を変えての実行・実行結果

初期の指定ではジョブスクリプト中で『#PJM --mpi "proc=1"』として

プロセス数を 1としたが、この部分を 1~32で変更し使用するプロセス数を変更する事で

どの様な影響が出るのかを調べる。17プロセスを超える場合は『#PJM -L "node=1"』の部分で

ノード数を 2に変更して実行する。

実行結果は以下の様になった[表 1][図 1]。

表 1 実行結果 図 1 実行結果のグラフ化

プロセス数 秒数（秒）

1 2.0976422 1.050613 0.6985594 0.5252355 0.420086 0.3500417 0.3003228 0.2628169 0.23339310 0.21067411 0.19125412 0.17511913 0.16186814 0.15345415 0.14087216 0.13208417 0.12419318 0.11702119 0.1108120 0.10542321 0.10054822 0.09590623 0.09187524 0.08795525 0.08445626 0.0809527 0.07846228 0.12874829 0.12485230 0.18263731 0.14342932 0.066093

4

■考察

課題 2では FX10のプロセス数を変更する事による実行速度の変化の確認を行った。

まず実行結果 [表 1][図 1] を見てわかる事は、当然ではあるがスレッド数の時の様にプロセス数を

増やすと処理時間が短くなる、という事である。

しかし、その短縮具合もまたスレッド数と同様に一定ではなく、プロセス数 1から 3までは

半分近くほどずつ短縮出来ているのに対し、プロセス数 8辺りから 27まではほんの少ししか

時間の短縮が出来ておらず、加えてプロセス数 28～31ではむしろ増加し何故か 32で増加する以前の

プロセス数 27より断然短縮される自体が起きた。これ自体が偶然なのかも知れないが、

これも False sharingの影響であると考えられる。

実際に直前や、1プロセス時と比較してどの程度の短縮が出来ていたかを以下に示す。

表 2 プロセス数－1とプロセス数 1 との比較

プロセス数 短縮率（直前） 短縮時間（直前） 短縮率（対1プロセス） 短縮時間（対1プロセス）

1 100.00% 0 100.00% 02 49.91% 1.047032 49.91% 1.0470323 33.51% 0.352051 66.70% 1.3990834 24.81% 0.173324 74.96% 1.5724075 20.02% 0.105155 79.97% 1.6775626 16.67% 0.070039 83.31% 1.7476017 14.20% 0.049719 85.68% 1.797328 12.49% 0.037506 87.47% 1.8348269 11.20% 0.029423 88.87% 1.86424910 9.73% 0.022719 89.96% 1.88696811 9.22% 0.01942 90.88% 1.90638812 8.44% 0.016135 91.65% 1.92252313 7.57% 0.013251 92.28% 1.93577414 5.20% 0.008414 92.68% 1.94418815 8.20% 0.012582 93.28% 1.9567716 6.24% 0.008788 93.70% 1.96555817 5.97% 0.007891 94.08% 1.97344918 5.77% 0.007172 94.42% 1.98062119 5.31% 0.006211 94.72% 1.98683220 4.86% 0.005387 94.97% 1.99221921 4.62% 0.004875 95.21% 1.99709422 4.62% 0.004642 95.43% 2.00173623 4.20% 0.004031 95.62% 2.00576724 4.27% 0.00392 95.81% 2.00968725 3.98% 0.003499 95.97% 2.01318626 4.15% 0.003506 96.14% 2.01669227 3.07% 0.002488 96.26% 2.0191828 -64.09% -0.050286 93.86% 1.96889429 3.03% 0.003896 94.05% 1.9727930 -46.28% -0.057785 91.29% 1.91500531 21.47% 0.039208 93.16% 1.95421332 53.92% 0.077336 96.85% 2.031549

5

ここで 2列目『短縮率（直前）』は、例えばプロセス数 4の時、プロセス数 3と比べて何%短縮したか

を表している。3列目『短縮時間（直前）』も単位を％でなく秒として同様である。

4列目『短縮率（対 1プロセス）』は、プロセス数 1と比較した時に何％の時間を短縮できたか

を表している。3列目、5列目の単位は秒であり、最終的には約 2秒、97％程度の短縮になっている。

以上でわかるのは、スレッドの時と同じ様に、生成の時間がボトルネックになってしまい、

今回で言えば恐らく一定のノードには一定の限界が存在する事であり、またキャッシュラインの

同時アクセスなどが起こり得る限り常に最良の性能である事は設計しない限り保証され得ない事である。

また今回は課題 1で測定したスレッド数を変更しての実行速度の変化との比較を行う。

取得したデータは以下である。また参考の為に表 1のプロセス数の変更版も併記する。

表 3 スレッド数を変えての実行結果 表 1 プロセス数を変えての実行結果（記載 2 度目）

スレッド数 秒数（秒）

1 2.9699532 1.5085043 1.0214624 0.7772215 0.6330996 0.5373237 0.4691478 0.4190729 0.38075810 0.34944711 0.32613912 0.30552713 0.28812114 0.27384515 0.26320416 0.25277617 0.25191418 0.250319 0.2999820 0.60158821 0.25239622 0.25045523 0.25104924 0.31064725 0.25329126 0.25222627 0.31084628 0.25381429 0.250630 0.25120431 0.25198632 0.252203

プロセス数 秒数（秒）

1 2.0976422 1.050613 0.6985594 0.5252355 0.420086 0.3500417 0.3003228 0.2628169 0.23339310 0.21067411 0.19125412 0.17511913 0.16186814 0.15345415 0.14087216 0.13208417 0.12419318 0.11702119 0.1108120 0.10542321 0.10054822 0.09590623 0.09187524 0.08795525 0.08445626 0.0809527 0.07846228 0.12874829 0.12485230 0.18263731 0.14342932 0.066093

6

またこれら[表 1][表 2]をグラフにして可視化したものが以下である[図 2]

図 2 並列化数を変えた実行結果のグラフ

なおどちらも反復回数は 100000000回としてある。

まずプロセス数を変更した方が高速である事が一見して見て取れる。

どちらも概ね同じ様なペースで時間を短縮させてると言える。

しかし概念的にはプロセス∋スレッドであるはずなのに何故プロセスの方が速いのか、

またなぜ並列化以前から１スレッドと 1プロセスで 1秒近くも差が出たのかを考えた時に、

コンパイル時のオプションとしてつけた-Kopenmpと-Kfastが関わっているのでは無いかと思われる。

速度などの比較をしたいのであれば、同様の条件でコンパイルすべきであった事を反省点として挙げたい。

また 1度目に実行した際に

『jwe1050i-w The hardware barrier couldn't be used and continues processing using the software

barrier. taken to (standard) corrective action, execution continuing.』と言うのが出力ファイルに出力

されていたのだが、n(試行回数)や i(繰り返し制御の変数)を long型にする事で最終的には出力されなく

なり、改善した。

7

自分なりに調べて見た結果として、参考サイト[1]には

『FX10に実装されているハードウェアバリア機能が利用できない場合に表示されます。

(FLIB_FASTOMPを FALSEに設定しているため)動作に問題はありません。』

と記載されていたのだが、何故今回のプログラムで出力されたのかは調べきれなかった。

ただプロセス数が多ければ多いほどたくさん出力されたので、全体の問題というよりは 1プログラムの

実行中の問題であり、また型を変えただけかどうかが少し曖昧であるため、プログラムを書く際に

ソース管理の一環としてバージョンの管理も行うべきであったかもしれない。

結果のまとめとして、

① プロセス数を増やすと総処理速度は上がる

② しかし速度向上にも限界があり、プロセス数を増やせば増やすほど良いという訳ではない

③ 予期せず全く不規則に時間が掛かってしまうことも有り得る

④ 今回の実験においては、スレッド数を増やすよりプロセス数を増やす方が早かった

⑤ ④はコンパイル時のオプション指定による結果である可能性が高い

⑥ そういった事があるため、実験時の環境は極力同等にする必要がある

⑦ 今回の実験においては、プロセス・スレッド共に、増やす事による速度向上率は概ね

同じであると言って良い水準であった

⑧ しっかり設定をしないと『The hardware barrier couldn't be used～』といったような出力がされる

事がある

⑨ シェルスクリプト（ジョブスクリプト）は書き方次第で非常に効率化出来るので習得すべきである

という事がわかった。

■参考

[ 1 ]波内 良樹 GROMACS実習 p7 独立行政法人理化学研究所 HPCI計算生命科学推進プログラム

http://www.scls.riken.jp/wp-content/uploads/2013/12/scls_GROMACS_lecture.pdf (2014/08/04閲覧)