Parallel computation foundation's assignment 1. This is my first time using thread partitioning.

1. 提出日：2014 年 8 月 2 日
並列計算
課題１
T2C_（Twitter : @T2C_ ）

2. 1
■課題内容
『FX10 実習 1 回目』のプリントの手順に従って、プログラムを FX10 上で実行する。
余裕があればスレッド数を変化させてそれぞれ実行時間を計測する。
■環境のセッティング
FX10 のログイン方法のページ[ 1 ]に従い FX10 へのログインを行う。
手順としては公開鍵・秘密鍵の作成→登録→Putty.exe、WinSCP を用いて接続、
と行った。
図１ 実際のログイン後の画面（Putty.exe） 図２ 実際のログイン後の画面（WinSCP）
■ソースコードの作成、転送、コンパイル、実行
プリントに記載されているソースコードに時間計測用のコードを付加し、WinSCP で転送し、
コマンド fccpx –o test –Kopenmp omptest1.c を打ち込みコンパイルを行った。
以下に実際の C、それからジョブスクリプトのソースコードを記載する。
なおプリントには num_steps = 10000 となっているが、実行数が少なく
短時間で終了してしまい時間計測の精度が悪くなると予想されるので
実行時の num_steps は 100000000 とした。

3. 2
――――― 以下 ソースコード（C） ―――――
#include <omp.h>
#include <stdio.h>
static long num_steps = 100000000;
double step;
int main()
{
int i;
double x,pi;
double sum = 0.0;
step = (double)1/num_steps;
double time1=0, time2=0;
time1 = omp_get_wtime();
#pragma omp parallel for reduction(+:sum) private(x)
for(i=0;i<num_steps;i++)
{
x = (i+0.5)*step;
sum += 4.0 / (1.0+x*x);
}
time2 = omp_get_wtime();
pi = step * sum;
printf("%16f¥n",pi);
printf("time : %lf¥n¥n",(time2-time1));
}
――――― ソースコード（C）ここまで ―――――

4. 3
――――― 以下 ソースコード（ジョブスクリプト） ―――――
#!/bin/bash
#------ pjsub option ------#
#PJM -L "rscgrp=debug"
#PJM -L "node=1"
#PJM -L "elapse =1:00"
#PJM -j
#------ Program execution ------#
export OMP_NUM_THREADS=1
./test
――――― ソースコード（ジョブスクリプト）ここまで ―――――
■実行結果
3.141593
time : 2.964754
と出力された。上は円周率、下は並列化した部分の実行時間である（単位：秒）。
■スレッド数を変えての実行・実行結果
初期の指定ではジョブスクリプト中で『export OMP_NUM_THREADS=1』として
スレッド数を 1 としたが、この部分を変更し使用するスレッド数を変更する事で
どの様な影響が出るのかを調べる。
実際はジョブスクリプトのソースコードを繰り返し制御するよう
for((i=1;i<=16;i++))
{
export OMP_NUM_THREADS=$i
./test
}
とし、スレッド数 1~16 で実行させるようにした。実行結果は以下である[表 1][図 3]。

5. 4
表１ 実行結果 図３ 実行結果のグラフ化
■考察
今回は FX10 の使用方法の確認と簡単な並列化による実行速度の変化の確認を行った。
まず実行結果 [ 図 3 ] を見てわかる事は、当然ではあるがスレッド数を増やすと
処理時間が短くなる、という事である。
しかし、その短縮具合は一定ではなく、スレッド数１から２では半分近く短縮出来ているのに対し、
スレッド数 15 から 16 ではほんの少ししか時間の短縮が出来ていない。
どの程度の短縮が出来ていたかを以下に示す。
表 2 スレッド数－1 とスレッド数 1 との比較
スレッド数 短縮率（直前） 短縮時間（直前） 短縮率（１スレッド） 短縮時間（１スレッド）
1 100.00% 0 100.00% 0
2 49.21% 1.461449 49.21% 1.461449
3 32.29% 0.487042 65.61% 1.948491
4 23.91% 0.244241 73.83% 2.192732
5 18.54% 0.144122 78.68% 2.336854
6 15.13% 0.095776 81.91% 2.43263
7 12.69% 0.068176 84.20% 2.500806
8 10.67% 0.050075 85.89% 2.550881
9 9.14% 0.038314 87.18% 2.589195
10 8.22% 0.031311 88.23% 2.620506
11 6.67% 0.023308 89.02% 2.643814
12 6.32% 0.020612 89.71% 2.664426
13 5.70% 0.017406 90.30% 2.681832
14 4.95% 0.014276 90.78% 2.696108
15 3.89% 0.010641 91.14% 2.706749
16 3.96% 0.010428 91.49% 2.717177
スレッド数 秒数（秒）
1 2.969953
2 1.508504
3 1.021462
4 0.777221
5 0.633099
6 0.537323
7 0.469147
8 0.419072
9 0.380758
10 0.349447
11 0.326139
12 0.305527
13 0.288121
14 0.273845
15 0.263204
16 0.252776

6. 5
ここで 2 列目『短縮率（直前）』は、例えばスレッド数 4 の時、スレッド数 3 と比べて何%短縮したか
を表している。3 列目『短縮時間（直前）』も単位を％でなく秒として同様である。
4 列目『短縮率（１スレッド）』は、スレッド数 1 と比較した時に何％の時間を短縮できたか
を表している。3 列目、5 列目の単位は秒であり、最終的には約 2.7 秒、91.5％程度の短縮になっている
が、その減衰は緩やかである。
これはスレッド数を増やすにつれてプログラムを処理する速度自体は上がっているが、
スレッドを生成する時間だけ総処理時間が延びてしまっていることが原因として考えられる。
また授業の中ではスレッド数は 16 までと教えていただいていながらも、気になったので
スレッド数 17~32 のでも実行し（ただし 16 スレッドで実行される？）、結果を見てみると[表 3]
表 3 スレッド数 17 以降の実行結果
となっており、ほとんど頭打ちであるどころか時たまに遅くなり、中には 20 スレッド（目）時のように
処理時間が大変大きくなってしまう事もあるようだ。多くのスレッドを生成する事でメモリの参照に
変に時間を掛ける、つまり False Sharing が起きている可能性もある。
結果のまとめとして、
① スレッド数を増やすと総処理速度は上がる
② しかし速度向上にも限界があり、スレッド数を増やせば増やすほど良いという訳ではない
③ 予期せず全く不規則に時間が掛かってしまうことも有り得る
④ 並列処理のプログラムを書く時には、これらも考慮して設計する必要がある
という事がわかった。
スレッド数 秒数（秒）
17 0.251914
18 0.2503
19 0.29998
20 0.601588
21 0.252396
22 0.250455
23 0.251049
24 0.310647
25 0.253291
26 0.252226
27 0.310846
28 0.253814
29 0.2506
30 0.251204
31 0.251986
32 0.252203

7. 6
■参考
[ 1 ] FX10 スーパーコンピュータシステム ログイン方法 [東京大学情報基盤センタースーパーコンピュ
ーティング部門] http://www.cc.u-tokyo.ac.jp/system/fx10/fx10-login.html