第3章 ハイエンドコンピューティング研究開発の動向
3. 種々のプログラミングインタフェースの比較
3.1 MPI（Message Passing Interface）
メッセージパッシングは、プロセッサ間のデータ転送を、ユーザがライブラリを用いて明示的に記述する枠組である。SPMD（Single Program
Multiple Data Stream）形式に基づいて、複数の制御の流れを意識したプログラミングが必要になる。
MPI（Message Passing Interface）は、分散メモリ型のプログラミングインタフェースとして、現在、最も標準的に用いられているものである。仕様はMPIF（MPI
Forum）と呼ばれるプライベートなフォーラムで検討され、1994年6月にMPI1.0がまとめられた。その後、並列I/Oやプロセスの動的生成・消滅、1方向通信（One
Sided Communication）などの機能をさらに追加したMPI2.0[4]の言語仕様が1997年7月に定められた。MPIの詳細についてはホームページhttp://www.mcs.anl.gov/mpi/
を参照されたい。
MPIは、現在、大半の商用並列マシン上でサポートされている。これらのMPIにはArgonne国立研究所とMississippi州立大学との共同で開発されたMPICH[5]
（http://www.mcs.anl.gov/mpi/mpich/ 参照）をもとにしたものが多い。MPICHは仮想デバイスの概念を導入することにより、システム依存部がコンパクトに切り離された構造になっており、移植性が高い。ベンダは、システム依存部を対象ハードウェアに適するように開発することで、効率の良いMPIを実装することができる。
3.2 VPP Fortran
VPP Fortranは、もともとNWT（Numerical Wind Tunnel）をターゲットとして開発された言語であり、日本におけるデータ並列言語としては、もっとも成功したものである。指示行形式を中心にFortranに最小限の拡張を加え、データマッピングと計算マッピングの両方を利用者に指定させる。言語拡張のそれぞれの要素を見ると、非常にHPFと非常に良く似た構成になっているが、言語の設計コンセプトはかなり異なる。もっとも大きな相違は、HPFがデータマッピングのみを指定させ、計算マッピングをコンパイラの自動処理に期待しているのに対して、VPP
Fortranでは、コンパイラの自動処理に期待するものは非常に少ない。データマッピングも計算マッピングも性能に影響を与えるものは、すべて利用者に明示的に指定させ、コンパイラに負担をできるだけかけずに、高い性能を得られることを目指して設計されている。
データマッピングについては、ローカルデータとグローバルデータという2種類が用意されている。グローバルデータは、HPFの分散データと同様に、分散メモリ上にblock分割またはcyclic分散を用いて配置することができ、プロセッサをまたがってのアクセスが可能である。ローカルデータは、プロセッサごとに重複して領域が用意されるもので、他のプロセッサのデータアクセスはできない。グローバルデータへのアクセスは低速であるため、分散配置されたグローバルデータのうち、自プロセッサが持つ領域（オーナー領域）とローカルデータをFortranのEQUIVALENCE文で結合し、計算処理などで頻繁にアクセスする場合には、ローカルデータとしてアクセスすることが推奨される。
計算マッピングについては、複数プロセッサで実行すべき部分をPARALLEL REGIONとして指定し、この部分がSPMD的に実行される。下記の例では、配列a,bの分散をPartition
Dとして宣言したものにしたがって指定し、さらに同じ分散をもとにSPREAD DOとしてDOループのマッピングに指定することにより、計算マッピングとデータ分散の両方を指定している。
（VPP Fortranの例）
!XOCL PROCESSOR P（4）
dimension a（400）,b（400）
!XOCL INDEX PARTITION D=（P,INDEX=1:1000）
!XOCL GLOBAL a（/D（overlap=（1,1）））, b（/D）
!XOCL PARALLEL REGION
!XOCL SPREAD DO REGIDENT（a,b） /D
do i = 2, 399
dif（i） = u（i+1） - 2*u（i） + u（i-1）
end do
!XOCL END SPREAD
!XOCL END PARALLEL
3.3 Co-Array Fortran
Co-Array Fortran[*]は、もともとF--という名で呼ばれていたもので、CRAYが開発したデータパラレル言語である。Fortran95に、データマッピングを記述するための簡単な言語拡張が施されている。プログラミングモデルはMPIと同様にSPMDであり、プログラムはimageと呼ばれる、独立したメモリイメージを持つ実行ストリームがプログラムを重複して実行する。Fortranにデータマッピングを追加したという意味では、HPFと同じであるが、大きな違いは、HPFがシングル実行イメージであるのに対して、Co-Array
FortranはSPMDをベースにしている点である。言語拡張のポイントは、co-arrayと呼ばれる新たな配列を付加して、どの実行イメージ上のデータかを指定した配列アクセスを許すという点である。
（例）
REAL, DIMENSION（N）[*] :: X,Y
X（1） = Y（1）[Q]
この例では、配列X、YというサイズNのco-arrayが定義されており、配列宣言に[*]が付け加えられることで明示的にco-arrayであることが示される。co-arrayは、すべての実行imageの上に宣言されたサイズ（この場合はN）の領域が重複して確保される。co-arrayへのアクセスにはローカルアクセスとグローバルアクセスの2通りの方法がある。グローバルアクセスとは、配列参照に[ ]指定を追加するもので、上記の例では、Y（1）[Q]の参照がこれにあたる。[ ]の中には、実行imageを指定し、この場合には、image QのY（1）が参照される。ローカルアクセスは、[ ]指定なしでの配列参照であり、この場合は左辺のX（1）がこれにあたる。ローカルアクセスは、実行中のimage上に確保されたco-arrayをデータ転送なしでアクセスする手段であり、たとえば、実行中の自imageがmeなら、X（1）とX（1）[me]は同じものである。ただし、X（1）[me]へのアクセスはデータ転送を含めたアクセスが仮定されるので、（コンパイラの最適化にも依存するが）性能が劣化することを覚悟する必要がある。
ローカル/グローバルというco-arrayへのデータアクセスは、非常にVPP Fortranのそれと近い。VPP Fortranでもローカルアクセスとグローバルアクセスを許すが、こちらはグローバル変数とローカル変数を別々に宣言して、この両者をequivalence文で結合することにより実現している。
Co-array Fortranのもう一つの特徴は、並列化のモデルがSPMDということである。imageというのは、論理的実行単位（MPIでのrank、HPFでいうところの論理プロセッサ）であり、その数は、必ずしもプログラムを実行するシステムのプロセッサ数と一致する必要はないが、簡単のためにimage数とプロセッサ数が同一として議論を進める。SPMDモデルにおいてはMPIと同様に、記述されたプログラムの複製が、すべてのプロセッサ上で非同期的に実行される。あるimageが生成したデータを別のimageでco-arrayを介して引用する際には、明示的に同期を挿入する必要がある。
3.4 Global Arrays
GA（Global Arrays）は、ライブラリ呼び出しの形で共有メモリビューを提供するインタフェースであり、FortranやC、C++などの言語と一緒に用いることができる。MPI処理系などのメッセージパッシングインタフェースの上にも実装されており、この場合、メッセージパッシングインタフェースと混在して用いることができる。
基本的な機能は、グローバル配列（GA）の宣言、およびGAへの一方向通信によるアクセス（putとget）、データ一致制御のための同期、総和などの上位機能、GAの格納アドレスのなどの情報取得機能である。機能的には、後述のCo-Array
Fortranと非常に似ているが、これらのGA操作をすべてライブラリ呼び出しの形式で実装されている点が異なる。メッセージパッシング関数が、プロセッサ識別子（MPIではrank）とアドレスの組によりデータ転送の対象を指定するのに対し、GAでは、配列要素番号によるアクセスが可能であり、明示的にデータ格納先のプロセッサを意識する必要はない。具体的には、
nga_create（type, ndim, dims, array_name, chunk, g_a）
で、n次元のGAを宣言でき、これに対して
subroutine NGA_Put（g_a, lo, hi, buf, ld）
subroutine NGA_Get（g_a, lo, hi, buf, ld）
でput/get操作が可能である。
同期用のルーチンも用意されており、データ一致制御の必要に応じて挿入する必要がある。また、総和などのcollective通信を行うルーチンも用意されている。
3.5 OpenMP ＋ DSM
DSM（分散共有メモリシステム）システムとは、物理的に分散配置されたメモリを共有メモリとして構成したシステムであり、論理的にはすべてのアドレス空間を通常のロード、ストア命令でアクセスできる。ただし、物理的には分散配置されているので、自プロセッサに直接接続されたメモリへのアクセスは高速だが、他のプロセッサに接続されたメモリへのアクセスは低速となる。ハードウェアサポートを持つ分散共有メモリマシンと、ハード的には分散メモリシステムで、この上に純粋にソフトウェアだけでDSMを実現するソフトウェアDSMがある。
ソフトウェアDSMを実装し、この上で共有メモリ用の並列化インタフェースであるOpenMP［4］を用いることにより、分散メモリシステムのプログラミングインタフェースを実現することができる。OpenMPは、主に、ループの各繰り返しや計算処理のまとまりを単位として、これらを別々のプロセッサで実行させることをユーザに明示的に指示させる。たとえば、ループを並列化する場合、ループを!$OMP
OMP DO 〜 !$OMP END DOで囲むことにより、各繰り返しを並列実行させることができる。
OpenMPは共有メモリが対象であるため、データの分散メモリ上への配置については、ユーザは指定できない。ある計算処理とそれに用いられるデータが同じプロセッサとメモリにあれば高速処理ができるが、これらを全く考慮しなければ、大半の計算処理でのメモリアクセスがネットワーク経由となり効率低下を招く[5]。このための制御（Affinity制御と呼ばれる）をコンパイラ、ユーザでどのように分担するか、またその際の言語インタフェースはどうすべきかが重要である。OpenMPを拡張して、DSMへの配列のデータマッピングを指定される拡張や、First
Touchという、最初にアクセスしたプロセッサメモリにデータを配置するような制御をコンパイラで行う方法が提案され、一部のコンパイラには実装されている。
4. プログラミングインタフェースの比較
前節で説明した種々の並列化インタフェースを比較すると、これらの違いのポイントとしては、下記のものが挙げられる。
（1）並列化インタフェースの形式（言語拡張、指示行追加、ライブラリ呼び出し）
最も融通の利くのが、言語そのものに手を入れる言語拡張だが、開発コストは最も高い。指示行形式にすると、コンパイラに手を入れる必要がある点では、言語拡張と同じだが、既存言語と指示行言語の処理（たとえば構文解析処理など）を比較的切り分けられるため、開発コストが下がる。ライブラリ呼び出しは、コンパイラに手をいれずに済むため、もっとも手軽な実装が可能だが、ライブラリ呼び出しのオーバヘッドが必要になったり、ライブラリ化することで、コンパイラの最適化が阻害されたりする場合がある。
（2）並列化指定（計算マッピング指定 AND/OR データ分散指定）
計算マッピングとデータ分散指定をどのように切り分けるか。先に述べたとおり、分散メモリシステムの分類においては、言語機能そのものという意味では最も大きな違いが出る部分である。HPFの取ったデータ分散指定をさせるという考え方は、シンプルで筋の良いものだと思う。問題点は、手続き間の扱いであろう。Fortran90できれいに書かれたコードは良いが、データマッピング指定は、コンパイラなどの処理系が配列の論理イメージと物理的アドレス上運のイメージのマッピングを管理する必要があるため、手続き間の扱いに弱い。最適化のために手続き間で異なる形状の配列として、FortranのReference呼び出しをされると、コンパイラはお手上げとなる。これはGAやCo-Array
Fortran、 VPP Fortranのいずれにも当てはまる。データ並列言語を普及させるには、手続き間の配列をどのように扱うべきかというプログラミング方法論を確立し、ユーザが物理的メモリイメージを考慮してコーディングするケースを減らしていくしかないかもしれない。
（3）コンパイラの自動化への期待度
コンパイラの自動化にどこまでを期待するかによっても分類できる。特殊な例を除けば、ライブラリ呼び出し形式のMPIなどは、コンパイラに何も期待しないし、完全自動並列化はすべてを求める。VPP
FortranやGAやCo-Array Fortranも、コンパイラにほとんど期待しない形式になっている。最近、HPFとMPIの中庸を求める動きの中で、これらのインタフェースが再度注目を浴びている。
（4）インタフェースの美しさ
インタフェースの完備性、仕様の美しさもインタフェースのよしあしを決める上で大きな要素となる。シンプルな美を持つ仕様がもっとも望ましいが、特定ケースの対応ができず、実用上問題がでる場合が多い。かといって、実用性を追求していくと、インタフェースの肥大化や複雑化を招く。特定機能を追加することで、おもいもかけなかった副作用が他の機能に発生することも、よくある。HPFも、JAHPFも言語標準化活動において、大半のエネルギーを言語の完備性を求めることに費やしている。計算機言語は、要素機能の無限の組み合わせによりプログラムを記述できるため、ミスのない、きれいな開発は非常に困難である。これらの活動には、忍耐強い論理的思考能力が要求されるが、HPFではCM
Fortranを開発したGuy Steelが、複雑な仕様を纏め上げる過程で大きな役割を果たした。活動の最終局面では、言語仕様の細部の詰めを、なかなか皆で追いきれず、Guyの能力に依存する局面が多かった。ある意味で、HPFは言語の完全性、美しさを追求しすぎたきらいがある。その点、VPP
Fortranは、完備製や美しさをある程度犠牲にして、実用性を追求した言語であると言える。
5. HPFの今後について
利用者に最も大きな期待を寄せられた時期に、実用レベルのコンパイラを提供することができなかったことが最大の原因で、HPFは欧米では、忘れ去られようとしている。3年から5年遅れた。この機を逸したことで、これから再びHPFが爆発的に利用が広まるということは考えにくいが、分散メモリマシンにおいて、データ分散配置を指定させ、残りをコンパイラが処理するという考え方は的を射たものだと思っている。今後は、HPFでコード開発・並列化を加速できるユーザを地道に見つけ、少しずつ発展させていくことになると思う。
並列化インタフェースとしては、当面はMPIが中心となることは間違いないが、MPIと似通ったプログラミングモデルでありながら、データパラレルの考え方を導入して記述量の削減を狙うGAやCo-Array
Fortranも、インタフェースがシンプルで利用者の習得が容易なことから、今後の発展が期待できる。また、OpenMPにデータマッピング機能を付加するアプローチも面白いと思う[27][28][29]。MPIに比べて、とりあえず動く並列コードを作成することが非常に容易である点を評価したい。並列化インタフェースは、そのもののよしあしよりも、どこで用いられるかが、その後の存続という意味では重要である。Lindaという共有メモリスペースを提供する処理系は、ほとんどの人に忘れられているが、GAUSSIANの並列化に利用されているというだけで、現在でもかなりのニーズがある。
HPFの今後についての最大の懸案は、言語やコンパイラの問題というより、Fortranで並列プログラム開発を行うという用途が、今後どれだけ広がるかにあると思われる。新規コード開発において、Fortranの利用割合が減っていることや、並列コード開発も、スクラッチから開発するより、既存のMPIプログラムを改造していくケースが多い。並列化によりユーザの研究自体が大いに加速されるような逐次コードをできるだけ多く発掘してHPFを用いて並列化し、その有効性を地道にユーザにアピールしていく活動を継続することが重要である。特定用途であれ何であれ、何とかHPFを一人前の市民権をもった言語インタフェースとして確立されていくことを願っている。
参考文献
[1] High Performance Fortran Forum. 1997. High Performance Fortran Language Specification. Version 2.0. Technical Report TR, Rice University, January 1997.
[2] H. Sakagami, H. Murai, Y. Seo and M. Yokokawa, 14.9 TFLOPS Three-dimensional Fluid Simulation for Fusion Science with HPF on the Earth Simulator, SC2002, http://sc-2002.org/abstracts_papers/ab_paper17.html.
[3] Message Passing Interface Forum 1994. MPI: A Message-Passing Interface Standard, The International Journal of Supercomputing Applications and High Performance Computing, Vol.8, No. 3/4, pp. 165-416.
[4] http://www.co-array.org/welcome.htm
[5] http://www.emsl.pnl.gov:2080/docs/global/ga.html
[6] OpenMP Architecture Review Board, OpenMP Fortran Application Program Interface, Version 2.0, November 2000. （ http://www.openmp.org）
[7] Lenoski, D., et. al., The Stanford Dash Multiprocessor, IEEE Computer, 25（3）, March 1992, pp. 63-79.
[8] J. Laudon and D. Lenoski, The SGI Origin ccNUMA Highly Scalable Server, SGI White Paper, March 1997.
[9] 細見他、並列計算機Cenju-4の分散共有メモリ機構、情処論文誌Vol.41 No.05-17, 2000年4月.
[10] High Performance Fortran Forum. 1997. High Performance Fortran Language Specification. Version 2.0. Technical Report TR, Rice University, January 1997. http://www.crpc.rice.edu/HPFF/
[11] High Performance Fortran Forum and RIST 1999. High Performance Fortran 2.0 （In Japanese）, Springer-Verlag Tokyo, ISBN4-431-70822-7.
[12] http://www.nas.nasa.gov/Groups/HSP/UserGuide/
[13] http://www.csm.ornl.gov/pvm/pvm_home.html
[14] http://www.cs.rice.edu/~dsystem/
[15] http://www.labri.fr/Perso/~counilh/adaptor/
[16] T. Kamachi, et. al., Generating Realignment-Based Communication for HPF Programs, IPPS ’96, pp.361-371, 1996.
[17] Barbara Chapman, Piyush Mehrotra, Hans Zima, Programming in Vienna Fortran, Scientific Programming, 1992,
http://www.par.univie.ac.at/research/report/node15.html[18] R. Das, J. Saltz, R. von Hanxleden 1993, Slicing Analysis and Indirect Access to Distributed Arrays, Proc. of the 6th Workshop on Languages and Compilers for Parallel Computing, Portland, OR.
[19] http://www.vcpc.univie.ac.at/information/HUG/
[20] Fujitsu Ltd., VPP Fortran Programming, UXP/V, UXP/M Ver. 1.2, April 1997.
[21] Japan Association of High Performance Fortran, 1999, HPF/JA Language Specification Version 1.0, RIST （English version is available at
http://www.tokyo.rist.or.jp/jahpf/index-e.html）.[22] Siegfried Benkner, Erwin Laure, and Hans Zima. 1999. HPF+: An Extension of HPF for Advanced Industrial Applications. Technical Report TR 99-1, Institute for Software Technology and Parallel Systems, University of Vienna.
http://www.par.univie.ac.at/project/hpf+/
[23] H. Murai, et. al., Implementation and Evaluation of an HPF Compiler for Vector Parallel Machines, HPF/SX V2, 4th HPF User Group Meeting, Oct. 2000, Tokyo.
[24] K. Suehiro, et. al., Benchmarking Results of HPF/SX V2, 4th HPF User Group Meeting, Oct. 2000, Tokyo.
[25] Fujitsu Ltd., HPF Programming: Parallel programming （HPF version）, UXP/V Ver. 1.0, June 2000.
[26] T. Ogino, Global MHD Simulation Code of Earth’s Magnetosphere Using HPF/JA, 4th HPF User Group Meeting, Oct. 2000, Tokyo.
[27] Barbara Chapman, HPF Features for Locality Control on ccNUMA Architectures, HUG2000 Invited Presentation, Tokyo, Oct. 2000.
http://rist03.tokyo.rist.or.jp/jahpf/hug2000/presen/Chapman.pdf[28] 廣岡 孝志、太田 寛、菊池 純男、ファーストタッチ制御による分散共有メモリ向け自動データ分散方法、情処論文誌 Vol. 41 No.05-020, 2000年4月.
[29] K. Kusano, S. Satoh and M. Sato, Performance Evaluation of the Omni OpenMP Compiler, WOMPEI 2000, Oct. 2000, Tokyo.
http://pdplab.trc.rwcp.or.jp/Omni/home.ja.html