ＶＰＰでの並列化２ [Top][VPP]
- 目次
- 手続きのみの分割（UNIFY文）
- サンプラ（ｋ点並列）
- サンプラ（バンド並列）
- バンド並列化のチューンアップ
- 並列化雑感
さて、筆者のＶＰＰ上での並列化作業の続きを述べていきたいと思います。
大分長くなったので、２つに分割しました（６／２、１９９７）。
昨日（５／１３、１９９７）、物性研のＶＰＰ講習会に参加しました。「Ｖ
ＰＰ ＦＯＲＴＲＡＮ プログラミング」マニュアルも最初の頃と比べて、大変
良く（有用に）なっています。（入手は、物性研のＶＰＰの共同利用の権限を
持っているユーザー〔そうでなくても、どこかのＶＰＰを使用する権限を持っ
ているユーザーなら可〕なら、物性研か富士通に問い合わせれば、可能と思い
ます。）
ここで新たに認識した手法（別に今回初めて出てきた訳ではなく、以前から
ありましたが、筆者が十分に認識していなかった）について説明したいと思い
ます。
これは手続きのみ分割する手です。この時、手続き分割の対象となるデータ
（配列）の分割を行ないません。つまり、重複ローカル配列のままで、手続き
部分（ＤＯループ）を分割してしまいます。
これは、データ部分（配列定義部分）は何ら、グローバル宣言もローカル宣
言もせず、そのままで、ＤＯループをSPREAD DO文で分割します。重複ローカ
ル配列Ａ（１０００）は４つのＰＥそれぞれで定義され、それぞれのＰＥで配
列Ａの１から２５０まで、２５１から５００まで、５０１から７５０まで、７
５１から１０００までが演算（計算）されます。例えば、２５１から５００ま
で演算されるＰＥ上では、配列Ａの１から２５０までと、５０１から１０００
までのデータはなにもされずに、そのままです。演算によって内容が変わるの
は２５１から５００までのみです。
では、各ＰＥに細切れにある重複ローカル配列Ａのデータをどうやってまと
めるのでしょうか（このままでは、並列化されたＤＯループを抜けると、（多
分）どれか一つのＰＥ上の配列Ａのデータしか参照されません）？
解決方法としては二つあり、一つはUNIFY文を使う方法、もう一つはグロー
バル和を使う方法です。以下に簡単な例を示します。
方法１
!XOCL PARALLEL REGION
-----
!XOCL SPREAD DO /IP
DO 1000 I=1,1000
A(I) = A(I) + 1.0D0*I
1000 CONTINUE
!XOCL END SPREAD
!XOCL UNIFY(A(/IP))(ID)
!XOCL MOVE WAIT(ID)
-----
!XOCL END PARALLEL
UNIFY文で、各ＰＥ毎での重複ローカル配列Ａの細切れのデータを集めてま
とめます。
IPはINDEX PARTITION文で定義されるものです。IDはUNIFY文による動作によ
る各ＰＥ間の通信終了を待つためのフラグです。
方法２
!XOCL PARALLEL REGION
-----
DO 500 I=1,1000
A(I) = 0.0D0
500 CONTINUE
!XOCL SPREAD DO /IP
DO 1000 I=1,1000
A(I) = A(I) + 1.0D0*I
1000 CONTINUE
!XOCL END SPREAD SUM(A)
-----
!XOCL END PARALLEL
この場合、グローバル和を使うので、最終的にまとめられる重複ローカル配
列Ａは、並列化されたＤＯループに入る前に初期化しておく必要があります。
また、サブルーチン内で、整合配列や、擬寸法配列になっている重複ローカル
配列には、UNIFY文が使用できないので、このグローバル和による方法のみが
使用できます。
速度的には、方法１のUNIFY文による方法の方が少し速い場合が多いとのこ
とです。
この方法を使用する利点は、面倒なデータ分割をしなくてすむことと、その
ため、並列化するためのリコーディング作業が楽になることが挙げられます。
但し、データ分割しないので、各ＰＥ毎に重複ローカル配列が定義されてしま
うため、メモリーに関しては損をしていることになります。特に、大規模なシ
ステムを扱う場合には不向きな方法と言えます。
取り敢えず、既存のプログラムを並列化するための、第一段階としてなら十
分使える方法と考えられます。データ分割は第二段階以降に行ないます。
ここでは、ＶＰＰ上での並列化効率を調べる、サンプラ（性能測定）の話し
をしたいと思います。完全ではありませんが、並列化したプログラムがどの程
度の効率（性能）で、実際に動いているかを調べることができます。
筆者は、原研のＶＰＰ３００上で、サンプラを動かし、評価（性能測定）結
果を得ました。これらの結果を以下に示します。
尚、この時のコンパイル条件は、（frt -Aad -Wx
-Ps -Oe -Zo.vs revpe_d.f -o W10p.exe）です。
- まず、ＰＥ数が９の場合
real 1:51:37.37
user 15:54:22.64
sys 15:07.88
vu-user 13:16:25.56
vu-sys 0.00
TOTAL 7.83634329 1.00000000 8.84488499 0.11607806 0.00077543
- 次に、ＰＥ数が１０の場合
real 1:38:02.97
user 15:31:15.42
sys 14:46.16
vu-user 13:17:29.26
vu-sys 0.00
TOTAL 8.92556668 1.00000000 9.79855149 0.09204035 0.00086677
- 次に、ＰＥ数が１０の場合（NOBARRIER使用時）
real 1:24:36.03
user 13:22:49.90
sys 12:53.84
vu-user 11:22:48.73
vu-sys 0.00
TOTAL 8.90907242 1.00000000 9.79128870 0.09293171 0.00086156
- ＰＥ数が１５の場合
real 1:11:09.26
user 16:52:45.34
sys 16:26.48
vu-user 13:23:33.23
vu-sys 0.00
TOTAL 12.32816583 1.00000000 14.54248744 0.15541730 0.00142550
- ＰＥ数が１５の場合（NOBARRIER使用時）
real 1:01:28.36
user 14:34:07.25
sys 14:18.47
vu-user 11:28:10.38
vu-sys 0.00
TOTAL 12.29195125 1.00000000 14.53042299 0.15687644 0.00161193
各リストの最初の５行目まではtimexコマンドで出てくる結果で、プログラ
ムの実行時間を表しています。
各場合のTOTAL欄の値（これがサンプラとしての結果で、沢山出力された情
報から切り取ってきたもの）は、左側から、並列効果（上限は使用ＰＥ数、値
が大きいほど効果が高い）、並列化率（範囲０から１まで、大きいほど並列化
していることを示しているが、あまりあてにならない）、並列加速率（上限は
使用ＰＥ数、値が小さいほど、冗長実行部分が多い）、負荷バランス（範囲０
から１まで、値が小さいほど、効率良く各ＰＥに仕事が割り振られている）、
非同期転送待ち発生率（範囲０から１まで、値が小さいほどデータ転送待ち状
態が少ない）を意味しています。
計算条件は、プログラムrevpe_d.fにお
いて、平面波数３８５５、ｋ点数６４で、ｋ点並列で、５００回（２０回毎に
ストレスによるユニットセルの最適化あり）のイタレーションを行なった場合
のものを使用しました。
筆者としては、いまのところこれが並列化効率として良い方なのか、そうで
ないのか判断できていません。ただ、やはり並列計算における使用ＰＥ数が多
くなると並列化効率は落ちていくことが分かります（９ＰＥと１０ＰＥではほ
とんど差はありませんが、１０ＰＥと１５ＰＥでは明らかに、１５ＰＥの方が
効率が落ちています〔計算時間が１．５倍速くなっていない〕）。
また、荻津さんの情報公開（←既にアクセス不能）にあるように、SPREAD
DO文にNOBARRIERを付加すると、計算時間が幾
分短縮（この場合１０％程、荻津さんの場合では最大３０％短縮が可能とのこ
と）されます。自分のプログラムでは、SPREAD DO、END SPREADの前者のみに
NOBARRIERを付けています。単純に全てのSPREAD文（両方）に付けると正しい
結果を得られませんでした（各DOループ毎に調べれば、両方〔SPREAD DO、END
SPREAD〕に付けられるものもあるはずで、そこまでやればもっと速くできると
思われます）。
原研のＶＰＰ３００でのサンプラの使用するためのqsub用のsh（samp.shと
する）ファイルは以下のようになります。
cdで、実行ファイルW10p.exeがあるディレクトリへ移る場合、~/は使用せず、
フルネーム（この場合、/user_directory/full_name/mat/Gaと仮定）で指定し
て下さい。
#@$-s /bin/sh
#@$-q fu010dh
cd /user_directory/full_name/mat/Ga
FJSAMP=file:./samp.dat,type:rtime,interval:10
export FJSAMP
timex W10p.exe > g.g
fjsamp W10p.exe
samp.datがサンプラ（上のシェルスクリプトでは１０ミリ秒毎に割り込みが
入る設定になっている）が解析するためのデータを格納します。大変大きなファ
イル（この場合１００ＭＢ程度）になります。W10p.exeは測定すべき実行ファ
イル（１０ＰＥ用）です。そして、ジョブが終了すれば、並列化性能測定結果
がファイル（samp.shならsamp.sh.o????〔????は４桁の数字〕というファイル
名でシステムが出力するものです。これはサンプラ使用時のみに出力されるも
のではありません。原研のＶＰＰを使っているユーザーは分かると思います）
として出力されます。
尚、これらの実行に関しては、物性研で行なわれたＶＰＰ講習会及び、配布
資料「ＶＰＰ ＦＯＲＴＲＡＮプログラミング」を参考にしています。
ここでは、バンド（バンドレベル、バンドインデックス、エネルギーレベル
などとも言う）毎の並列化のサンプラ結果を示してみます。各並列化（ｋ点並
列、バンド並列）のまとめで書かれているように、バンド並列の方が、並列化
効率が良くないです。
特に、計算条件は上記ｋ点の場合と同じですが、イタレーション回数は
５００から３０
０に減っています。そして更に、サンプラの結果をみると、ｋ点並列
と比べて、著しく良くないと言えます。
もともとｋ点並列と比べて、バンド並列はグラム・シュミットの部分のよう
に、並列化効率を十分発揮できない部分もありますが、全体としての並列効率
はｋ点による場合とほとんど変わりません。事実、ＪＲＣＡＴ（現富士通）の
山崎さんのレポート（アトムテクノロジー研究体によるＶＰＰ５００の応用事
例。８／２６、２０１１、既に
[http://www.fujitsu.co.jp/hypertext/Develop/magazine/vol47-6/index.html]
はアクセス不能を確認）によれば、バンド並列での並列効果は非常に高いもの
になっています。
- ＰＥ数が１０の場合
real 1:37:00.62
user 15:20:11.79
sys 14:36.60
vu-user 8:20:18.05
vu-sys 0.00
TOTAL 5.72961764 1.00000000 8.74195274 0.29056272 0.07206081
- ＰＥ数が１０の場合（別バージョン）
real 1:26:28.81
user 13:40:06.70
sys 13:04.41
vu-user 7:59:13.96
vu-sys 0.00
TOTAL 5.42428914 1.00000000 7.79841089 0.27184931 0.03504373
- ＰＥ数が１０の場合（NOBARRIER使用時）
real 1:26:13.23
user 13:37:40.97
sys 13:07.47
vu-user 7:09:24.30
vu-sys 0.00
TOTAL 5.57812850 1.00000000 8.70883595 0.29232582 0.07953678
- ＰＥ数が１０の場合（別バージョン、NOBARRIER使用時）
real 1:25:44.23
user 13:33:22.27
sys 13:04.69
vu-user 7:59:15.47
vu-sys 0.00
TOTAL 5.48381464 1.00000000 7.88285496 0.26625146 0.03515316
- ＰＥ数が１０の場合（別バージョン、NOBARRIER使用時、Ofオプション）
real 1:35:40.73
user 15:07:37.91
sys 14:26.81
vu-user 9:10:11.47
vu-sys 0.00
TOTAL 5.66097793 1.00000000 8.05437490 0.26207811 0.03327758
- ＰＥ数が１５の場合
real 1:20:44.95
user 19:08:07.08
sys 18:51.61
vu-user 8:36:11.38
vu-sys 0.00
TOTAL 7.09841156 1.00000000 12.27205116 0.35313408 0.09508146
- ＰＥ数が１５の場合（NOBARRIER使用時）
real 1:12:46.44
user 17:14:44.19
sys 17:01.39
vu-user 7:24:59.21
vu-sys 0.00
TOTAL 6.88781217 1.00000000 12.28946853 0.34805725 0.10550688
以上の結果を見ても分かるように、Ofオプション（これ以外では-Oe）では、
むしろ遅くなっています（本当は最適化のレベルを上げている）。ｋ点並列と
比べてあまりにも効率が悪いので、更なるチューンアップが必要です。
昨日（６／１０）、物性研の短期研究会「物性研究における計算物理学―――
並列計算の現状と今後の展望」に参加しました。特に、並列化に関しては認識
を新たにしました。
この研究会に参加して新たに認識したこととは、ＶＰＰにおいて並列化効率
を上げて、計算を高速化するためには、徹底した並列化とチューンアップが必
要だということです（当然のことなのですが、並列化を行なっている研究者の
皆さんの貴重な話を改めて聞くと、なるほどと再認識することが多いです）。
特に、気付いたこととして、バンド計算に関して、いまのところバンド並列
が主に行なわれています。ｋ点に関する並列化は、バンド並列より簡単、効率
も良いのですが、系が大きくなると、相対的にｋ点数は少なくなるため、並列
化できなくなることが致命的です。
そして、ＶＰＰ上での並列化では、UNIFYによる並列化
が有効であることがわかりました。本ページの最初が、そのUNIFY文の説明で
あるように、事柄としては認識していましたが、この方法は自分がこれまで考
えた以上に有用です。
本ページ、サンプラ（バンド並列）についてのところ
を見れば分かるように、筆者のプログラムのバンド並列に関しての並列化効率
はあまり良くありません。
効率を下げている原因としては、グラムシュミットの部分の並列化に関して
の扱いが良くないことと、個々のルーチンのチューンアップが不十分であるこ
となどが考えられます。ここでは、後者のチューンアップについて述べていき
たいと思います。
チューンアップと言っても、いろいろな方法、手法が考えられます。ここで
は前述のようにUNIFYについて、特にどこらへんのルーチンが可能かについて
検討します。
UNIFY可能なルーチンとして、（１）ｋ点並列では並列化できたが、バンド
並列では並列化できないルーチンとしてKBINT
などがあります。このサブルーチンにはバンドに関してのループが存在しない
ので、バンド並列できません。このルーチンは動径方向のメッシュに関しての
並列化は可能なので、それで分割する手があります。一方、UNIFY文を使って、
ｋ点に関しての並列化をすることも可能です。この場合、配列SNLはメッシュ
数での定義はされていないので、もともと各ＰＥで定義されています。従って
UNIFYによるｋ点に関する並列化を行なったとしても、メモリーとしてはほと
んど損になりません（メッシュ関係の配列は大きくない）。またバンド並列を
行なうような系では、ｋ点数が非常に少ない場合（と考えられる）なので、そ
の点からもこれは許容できます。
同様に、サブルーチンDIAGON
もチューンアップ可能です。ｋ点並列では、DIAGONの大部分を（非常に大きな
ループとして）並列分割することができますが、バンド並列ではあまり大きな
ループ（対角化用サブルーチンを呼び出した後にバンドに関してのループ
がありますが、全体としては大きくありません）としての分割ができません。
従って、バンド並列をやめ、このルーチンは再びｋ点並列に戻すことが考え
られます。問題はこの場合、他のサブルーチンではバンド並列用のグローバル
配列であるものを、このDIAGONではｋ点並列として考えなければならないこと
です。つまり分割軸が変わってしまい
ます。
この場合、作業用の分割軸の異なるグローバル配列を用意し、SPREAD MOVE文を使って、分割軸の変更を行なう必
要が出てきます。そして、この場合どうしてもグローバル配列を直接扱う必要
が出てきます（ＰＥ間のデータの転送が伴う）。また、作業用のグローバル配
列も必要になるので、メモリーもその分損をします。従って、分割軸を変えて
本当に高速化できるかは試してみないと分かりません（まだ試してない）。
この他にも、原子数に関して、UNIFYを使った分割が可能なサブルーチンが
あります。例えば、エ
バルト和をとるもの、力の
計算（ローカル部分）、フォー
ムファクターの計算、分子
動力学部分などがあります。
もともと、これらのルーチンは冗長で実行されているので、UNIFY文を使っ
た並列化を行なっても、あまりメモリーとしての損はありません。
現在、筆者が並列化を行なうことができたシステムは、富士通のＶＰＰ上で
のみです（自動並列化による実行は除く）。よいしょするわけではないですが、
ＶＰＰはおそらく国内で一番多く出回っている、ベクトル並列（分散メモリー）
型マシンだと思われます。サポートするＳＥ等の質も高く（と言うより、他の
メーカーのＳＥが酷過ぎる？、これはあくまで並列化とスパコンに限定しての
ものです。）、システム（ＯＳ、コンパイラ、稼働率等）もまあ信用できます。
（５／２０）富士通ではスカラー並列計算
機であるＡＰ１０００、ＡＰ３０００上でも、ＶＰＰ ＦＯＲＴＲＡＮが動
く（それもちゃんと、ＶＰＰ用の並列化指示行を解釈して、並列実行する）よ
うにしています。つまりベクトル並列型スパコンＶＰＰ上で開発した（並列化
指示行形式で並列化を実現した）プログラムが、ＡＰシリーズでも並列で動い
てしまう訳です。
ＡＰ上のＶＰＰ ＦＯＲＴＲＡＮも完全なフルセット仕様なので、互換性は
非常に高いようですが、筆者も試したことはありません。とにかく並列で動作
させられるアーキテクチャが１つでも増えることは、（筆者にとって）大変良
いことだと思います。
特に、並列化指示行形式（他のマシンでは注釈として解釈される）での並列
化方法には賛否の分れるとこかもしれませんが、バンド計算の分野ではｋ点や
バンドの並列化を施したプログラムは、効率を無視すれば大抵そのままプログ
ラムが、他のスカラーマシンでも動きます。これは、デバッグやバージョン管
理が比較的やり易いことを意味し、並列化に関してエンドユーザー的な立場の
者にとっては決して悪い話しではありません。この点で富士通には頑張って欲
しいところです。（当然、クレイ、ＮＥＣ、ＩＢＭ、日立等スパコン屋、その
他の並列計算機屋さんも同じように頑張って欲しいです。）
但し、この世界の時間の流れは大変速く、今日の最新鋭マシンが明日には中
古品になってしまいます。従って、どのようなシステムやＯＳやコンパイラー
やマシンが本当に生き残るのかは、おそらく誰にもはっきりとは分からないと
思います。そういう意味ではＶＰＰに頼り切ることには、若干の危険が伴いま
す。
筆者が次に目指すのは、（イ）ＶＰＰ上でのプログラムの一層の最適化、
（ロ）他のシステム上での並列化への移行（移植）、が考えられます。特に
（ロ）について、おそらく将来生き残る並列化用の言語仕様はＭＰＩ、ＰＶＭ、
（ひょっとしたらＨＰＦの次のバージョン〔物性研の荻津先生談〕）、又はこ
れらの拡大、改良版と思われます。今後、筆者としてはこれらの言語、コンパ
イラー仕様に挑戦しようと考えています。
尚、再四（？）に渡り恐縮ですが、特に並列化に関して
は筆者は素人に毛の生えたレベルなので、記述内容や、考え方、捉え方の間違
いや誤解を指摘してもらえると大変有難いです。（メイルアドレス、
kobayashi.kazuaki-@-nims.go.jp、
"-@-"は変なメイル対策）
[先頭][総目次
][最初に戻る][ＶＰＰ３００、５００での並列化][ＳＸ４並列化][OpenMPによる並列化][並列化情報]