（石川 裕委員）
並列プログラミングパラダイムをデータ授受の観点から大別すると、メッセージパッシング型と共有メモリ型になる。
メッセージパッシング型の欠点は、システムソフトウエアによる通信データのバッファ管理に伴うメモリコピーのオーバヘッドが問題になる。これにより通信性能が高く通信路における遅延が小さくても、メモリコピーの性能で頭打ちになるケースが多い。
例えば、MPICHと呼ばれるMPIを実装したPDSに基づくIntel ParagonおよびPCクラスタ（表1）上での我々の経験［1］では、MPIのバンド幅およびレイテンシはParagon上で57 Mbytes/s、69 μsec、PCクラスタ上で26 Mbytes/s、35 μsecである。表と対比すると分かる通り、ほぼメモリコピーのバンド幅となっている。PCクラスタ上の我々が開発した通信ドライバPMでは、ユーザのメモリ空間に対して116 Mbytes/sのバンド幅を実現しているが、これを利用したMPIではユーザ空間にある通信バッファからアプリケーション側で指定している領域へのコピーのためにメモリコピーのバンド幅以下になっている。
| Processor | ||
| Clock | ||
| Network Bandwidth | ||
| Memory Bandwidth(memcopy) |
MPIのように同期通信がある場合には、システムは無駄なメモリコピーを削ることが可能となる。この場合、例えば、我々の環境では、ほぼ通信ドライバで実現されている116 Mbytes/sの性能をMPIレベルで出すことが可能となる。これがシステムソフトウエア側としては本質であるが、プログラミングをするユーザにとっては負担を強いることになる。通信遅延を隠蔽するために、あるいは非同期処理を実現するためには、同期通信＋マルチスレッドとする必要がある。
共有メモリ型プログラミングの利点は逐次処理プログラムからの移行がメッセージパッシング型に比べて楽な点である。しかし、例えば、ローカル計算＋一斉通信というパターンでは、通信時におけるネットワークのトータル転送容量の大きさが性能に効いてくる。ここにSMPのような並列計算機におけるバスの限界によるスケーラビリティの悪さが生じてくる。ランダムにメモリをアクセスをするような並列プログラムは共有メモリ型プログラミングが向いている。しかし、共有メモリ型のシステムでは、従来から言われている通りfalse sharingによる性能劣化の問題がある。
並列計算機用に使用されるプログラミング言語システムとしては、i）データ並列が可能な逐次プログラムを自動並列化するコンパイラを提供する、ii）コントロール並列記述を含めた並列処理記述構文を提供する並列プログラミング言語を提供する、の２種類がある。ここでは、ii）に関して議論する。
従来より並列プログラミングのために、より高機能な並列処理記述を提供する試みがなされてきている。研究成果物である新しい並列処理言語は、特定用途には、普及している例を幾つか見ることができるが、FortranやC、C++のように広く一般に普及し利用されている並列プログラミング言語はない。現在でも、新しいプログラミング言語の提案が多数発表されているのが現状である。これは、計算機利用の多様化に伴い、アプリケーションの性質に合致したプログラミング支援を必要としているからであろう。
このような状況では、ある特定用途のプログラミング言語システムを開発するよりも、ユーザのニーズに合わせたプログラミング構文を作成できるプログラミング言語システム、すなわちメタレベルアーキテクチャを持つプログラミング言語が必要である。
メタレベルアーキテクチャの中でコンパイル時メタレベルアーキテクチャでは、ユーザがコンパイル時に、コンパイラのパーザ、コード生成を変更することが可能となる。本機能を利用して、ユーザのニーズに合致する構文をユーザ自身が定義していくことが可能となる。
さらに、行列ライブラリを提供する人は、ライブラリを「組み込みライブラリ」の如く提供することができる。すなわち、ライブラリが呼び出されている環境をコンパイル時に知ることができ、その環境に適したコード生成を記述することができる。非常に簡単な例として並列基本行列計算ライブラリを考えてみる。
Y = A*X + Bは次のようなライブラリコールになるであろう。
従来の処理系では上記のライブラリコールは単なるライブラリコールの列としてしか生成できない。しかし、メタレベルアーキテクチャでは、上記のプログラムを展開し、一時変数をなくして最適化することが可能となる［2］。
ソフトウエア工学の分野では、再利用技術として、クラス、クラスライブラリ、フレームワーク、デザインパターン等と研究のシフトが進んでいる。デザインパターンとは、プログラミングにおける定石あるいは手筋をまとめたものであると言える［3］。ソフトウエア工学においては、ウインドウプログラミングやビジネスアプリケーション等においてデザインパターンの応用事例が多い。並列プログラミングにおいても、デザインパターンが重要であり今後の研究の発展が望まれるところである。
並列計算機を気楽に使える環境を提供するシステムソフトウエアが必要である。利用者はワークステーションを利用しているかのごとくシームレスに並列計算機が利用できる必要がある。ワークステーションで主流のUnix系を採用している現状の並列計算機上のOSは、このような環境を満たしているように見えるが問題点が多い。各プロセッサ上にローカルなUnix OSが独立して稼働しているために、グローバルな資源管理に基づく効率よい並列実行環境が提供されていない。そこで、いくつかの商用計算機では、UnixによるTSS環境とバッチ環境の２つを提供し、システム管理者は、ユーザのニーズに合わせ、TSSおよびバッチ環境のサービスをスケジュールすることをしている。
一方、Unix擬きのOSを開発し、ギャングスケジューリング等を採用することにより、並列マルチタスク環境を実現しているシステムも存在する。しかし、このようなシステムは、ワークステーション上ほどの豊富なプログラミング支援ツールが整備されず廃れていくことが多い。
コモディティOS環境を並列計算機上で効率良い実行環境を提供するシステムが必要とされている。現在、我々は、PCクラスタ上で、そのような環境を実現すべく研究開発を進めている［3］。並列OS、通信ドライバ、プログラミング言語を同時に設計し、ギャングスケジューリングを実現している。並列OSであるSCoreはUnix系の上に構築している。プログラミング言語はC++を拡張したMPC++と呼ぶ言語を開発している。
＜参考文献＞
（笠原博徳委員）
５〜10年後のペタフロップスマシン研究開発方針として重要なのは、ピーク性能だけではなく、アプリケーションを実行した時の実際の性能（実効性能）の向上を図るということである。これは、従来分散メモリ型マルチプロセッサを用いた超並列システムが高いピーク性能が得られるため注目されていたが、実効性能がピーク性能の数％から30％程度の低い値にしか達せず、より低いピーク性能をもつ共有メモリ型マルチベクトルプロセッサシステムの方が多くのアプリケーションに対して高い実効性能を与える［1］ことが知られるようになってから、米国を中心に科学技術計算に超並列型のマシンは適さないと理解され、超並列マシンを開発していた企業が事業から撤退していったことを見ると明らかである。
このように実効性能の高いペタフロップスマシン開発を行うためのキーとなるのは、コンパイラを始めとしたシステムソフトウエアの高度化［7、8］と、ソフトウエアにおける並列化技法の性能を最大限に引き出すことのできるアーキテクチャ［14］の開発すなわちソフトウエア／ハードウエア協調設計型マルチプロセッサシステムの開発である。もちろん、システムソフトウエアにおける並列処理方式の開発においては、各種のアプリケーションプログラムの並列性を十分に活かせるようにしなければならない。
また、高実効性能ペタフロップスマシンにおいて、多くのプロセッサを利用率高く動作させ、プロセッサ間データ転送オーバーヘッドおよび同期オーバーヘッドを低くおさえるために、ユーザが高度なチューニングを余儀なくされるというのでは、商業的成功は望めない。すなわち、ペタフロップスマシンといえども、誰にでも簡単に使いこなせるようなユーザフレンドリネスが重要と考えられる。このためには、ユーザが並列処理を意識することなく従来の使い慣れたＣあるいはFortranなどの言語でプログラミングを行うと自動的に並列化してくれるコンパイラ（このようなコンパイラでは原子力コードのようなFortranで記述された既存のプログラムの自動的な実行も可能）［2-5］、あるいはユーザはプログラミングを行わず、ユーザが使い慣れた問題記述法、例えば電力系統の解析であれば電力系統図、制御系であれば伝達関数、ロボットであれば関節およびリンクの構成などをグラフィカルインタフェイスを用いて入力すると、問題の求解プログラム（例えば電力系統過渡安定度計算のための非線形微分方程式求解プログラム）を内部で自動的に作成し並列化する専用目的コンパイラの開発が重要と思われる［2、12］。
以下では、ペタフロップスマシンの開発に向けて今後ますますその重要度が高まると考えられる自動並列化コンパイラ技術の現状と課題、またそれらの対処策の例について簡単に述べる。
（1）自動並列化コンパイラの現状
並列化コンパイラは逐次型言語あるいはその拡張言語で書かれたプログラムに、
等の処理を適用し、並列化マシンコード（あるいは並列化拡張言語）を生成するものである。
現在までに実用化されているマルチプロセッサシステム用自動並列化コンパイラの並列性抽出部では、プログラム中で最も多くの時間が費やされるDoループの並列化を対象にしており、ループ内のデータ依存解析［2、3、5］およびDoall, Doacrossループへの変換（ループ並列化）［4］が行われる。
ここで、データ依存解析とは、並列性抽出のために、命令間、ステートメント間、サブルーチン間、ループ間のデータの定義・使用関係により生じる一種の実行順序関係の制約を解析することであり、具体的にはフロー依存、出力依存、逆依存、入力依存、の４種類があるが、並列性解析ではフロー依存、出力依存、逆依存が解析され、入力依存はデータの分割配置を行う際に考慮される。
次に、制御依存解析とは、ステートメント等が並んでいる順序および条件分岐等を解析しながら、ある条件分岐の分岐方向が決定するとどのステートメントが実行可能になるかを解析することで、データ依存を考慮しない場合のステートメント間の最大の並列性を調べることができる［2］。しかし、実際にはデータ依存を考慮しながら並列性を解析することが必要であり、制御依存およびデータ依存を考慮して最大の並列性を解析する方法として最早実行開始条件解析［2、11、15］が提案されている。
またプログラム・リストラクチャリングでは、データ依存解析等の結果を利用して、Doall，Doacrossループに変換（ループ並列化）するほか、そのままではベクトル化あるいはループ並列化できないループを、
等各種の手法を用いて並列化を可能にする。
このループ並列化のためのプログラムリストラクチャリング手法に関しては、非常に多くの研究がイリノイ大学が中心に行われ［4、5、20］、現在は成熟期に入っている。
しかしこのようなループ並列化によるイタレーションレベル中粒度並列処理技術だけでは、アムダールの法則からも分かるように、プロセッサが数千以上のペタフロップスマシンの場合には並列化できないループやループ以外の処理部分の影響で、実効性能の向上を図ることは困難になる［18］。
（2）ペタフロップスマシン用自動並列処理化コンパイラの研究課題
上述のようなループ並列化技術の限界を考慮し、ペタフロップスマシン用自動並列処理化コンパイラでは、米国におけるペタフロップスワークショップでも一部議論されているように、以下のような並列化技術の開発が重要になると考えられる。
（a）のマルチグレイン並列処理は、ペタフロップスマシンにおけるプロセッサ間だけではなく、５年後から７年後にマイクロプロセッサの主流になると思われるシングルチップマルチプロセッサでも非常に重要となる技術である。
また（b）のデータの自動分割配置と（c）の処理のデータ転送のオーバーラッピング技術は、今後アーキテクチャ的にもコンパイラ的にも非常に重要な研究テーマになると考えられているソフトウエア（プログラム）制御キャッシュの開発のための基礎技術としても重要である。
（3）まとめ
本節では、商業的に成功するペタフロップスマシンの開発においては、実効性能および使い易さの向上が重要であり、このためには自動並列化コンパイラの高度化、コンパイラによる並列化技術の性能を最大限引き出すことのできるアーキテクチャの研究が重要であることを述べた。さらに、自動並列化コンパイラの現状と問題点を指摘し、今後マルチグレイン並列化、データ分割配置、処理とデータ転送のオーバーラップスケジューリングなどのコンパイラ技術を開発実用化して行くことが重要であることを説明した。
また、これらのコンパイル技術は、ペタフロップスマシンのみでなく、現在日本が米国に大きく遅れているRISC系プロセッサの開発において、５年後以降に世界をリードするプロセッサを開発するチャンスとなると考えられるシングルチップマルチプロセッサのアーキテクチャに大きな指針を与えると共に、そのようなプロセッサを効率良く動作させるためにも極めて重要な技術となると考えられる。
しかし現在のところわが国では、このような最先端の並列化コンパイラの研究を行う研究者の数が大学、企業、国研を通じて少なく、産官学協力し早急に人材を育成することが必要である。さらに、このコンパイラ技術は、将来のマイクロプロセッサからスーパーコンピュータまでの性能を左右する最重要課題の一つと考えられるので、国としても研究の推進を積極的に支援していく必要があると思われる。
＜参考文献＞
（妹尾義樹委員）
科学技術計算分野におけるペタフロップスマシンの実現を考えるとき、ユーザに使いやすく、しかも高いシステムの性能を引き出せるためのプログラミングインタフェースを提供することは不可欠である。このための要素技術、技術課題、将来の予想、技術調査のポイントについて述べる。
現在の科学技術計算の分野では、最高速のシステムのピーク性能が、数百ギガFLOPSから１テラFLOPSである。これらのシステムはすべて、分散メモリタイプの並列マシンであり、プログラミングインタフェースとしては、大きく分けて、メッセージパッシングによりSPMD（Single Program Multiple Data Stream）形式のプログラムをユーザが明示的に記述する枠組みと、データパラレルプログラミングの２種類がある。前者はMPI（Message澑assing Interface）［1］、後者はHPF（High Performance Fortran）［2］［3］が現在の代表的な標準インタフェースとして認知されている。いずれの場合でも、システムの高い性能を引き出すための鍵は、データアクセスローカリティーの抽出である。つまり、これらのシステムでは、演算性能に比べて、通信性能が計算のボトルネックになる場合がほとんどであり、データアクセスの局所性をうまく引き出して、必要となる通信量を最小にする必要がある。
MPIはメッセージパッシング、つまり、プロセッサ間のデータ転送を、ユーザがライブラリを用いて明示的に記述する枠組である。SPMD形式に基づいて、複数の制御の流れを意識したプログラミングが必要になる。これに対してHPFは従来のFortran言語に最小限の付加的指示で並列化を可能とすることを狙ったデータパラレル言語である。現在はまだ仕様そのものや処理系(コンパイラ)の完成度の面で発展途上であるが、大きな可能性を秘めるとともに、今後、分散メモリマシンを並列処理の専門家だけの研究ツールから実用ツールにするためには必須のプログラミングインタフェースである。このMPIとHPFについて、日米の技術的現状について比較を行う。
（1）MPI
MPIは、分散メモリ型のプログラミングインタフェースとして、現在最も標準的に用いられているものである。MPIは、米国のJ. Dongarra、 D. Walkerや欧州のR. Hempelらによって標準化が推進された。標準化はMPIF(MPI Forum)と呼ばれるプライベートなフォーラムで行われた。このインタフェースは、米国のPVM、P4や欧州のPARAMACSなどのメッセージパッシングインタフェースをベースに設計されており、現在では、並列I/Oやプロセスの動的生成・消滅などの機能をさらに追加したMPI2の言語仕様が検討されている。また、最近では、並列計算機用の標準ベンチマークとしてMPIで書かれたプログラムが開発されている。日本と欧米では、言語インタフェースに関する研究のみならず、その利用経験の蓄積において、まだかなりの開きがあると思われる。
（2）HPF
HPF言語の標準化活動もMPIと同様に、Rice大学CRPCのKen Kennedy教授を中心とするプライベートな組織HPFF(HPF Forum)で行われた。ANSIを中心に行われたFortran90の仕様制定に10年以上かかった反省からである。活動は1991年に開始され、1993年にHPF1.0が制定された[2]。その後もHPFF2において、仕様の曖昧性のチェックや、HPF1.0で不十分であった機能拡張が検討され、昨年末にHPF2.0［3］の仕様が定められた。HPFの標準化活動も、主に米国を中心として行われ、商用のコンパイラについてもPGIやAPRといった米国ベンチャーが日本のベンダに比べて先行している。HPF関連の技術についても、特にその利用技術の蓄積について欧米が日本に比べて格段に進んでいると思われる。特に米国では、TMC社（Thinking Machine Corporation）のConnection Machine上でCM-Fortranを用いたプログラミング経験が長く蓄積されており、現在のHPFで書かれた実用コードの多くはCM-Fortranプログラムを書き換えたものである。後で、さらに詳しく触れるが、日本の並列処理技術の発展のためには、コンパイラとユーザの緊密な共同作業による、利用経験の蓄積、利用環境の整備が急務である。
現在のデバイステクノロジの延長線上で、15年から20年先のスパンでペタフロップスマシンを実現するとすると、これは並列システム、それも少なくとも1000台以上の、かなり多数の要素プロセッサが結合された超並列システムとならざるを得ないと考えられる。また、これら多数のプロセッサを効率よく動作させるためには、物理的には、現在のテラフロップスマシンと同様に、分散メモリ構成にならざるを得ない。共有メモリでは、メモリアクセスがボトルネックとなり、システムの実効性能を制限するからである。
物理的に分散メモリで構成された並列プロセッサで性能の高いプログラムを記述する際のポイントは、データの分散メモリへのレイアウトである。結合された各プロセッサを可能な限り独立に並列動作させるためには、データアクセスのローカリティーを最大限に抽出する必要があるからである。
ペタフロップスシステムの実現を可能にするための言語処理技術について、そのニーズ、要素技術、パラダイムシフトについて述べる。
（1）ニーズ
科学技術計算の分野における、計算機システムに対するニーズについて、言語インタフェースに関連するものは以下のものであろう。
これらの各項目は、一般にはトレードオフの関係にある。すなわち、高速性だけを追求して、他を無視してよいならば、ユーザがアセンブラでプログラムを開発すればよく、複雑な言語処理系を開発する必要はない。逆に高速性を犠牲にして、他の項目を実現するのも容易である。実際には、要求される高速性を維持しながら、他の項目を高めていく必要があり、これには、一つ一つの言語処理系に関する要素技術を着実に完成させていく地道な努力が必要である。
（2）要素技術
上記で述べたニーズを実現するために必要となる要素技術について、特にHPFなどのデータパラレル言語の枠組みに話を絞って述べる。
HPF言語の現在の問題点は、並列化/通信最適化についての記述力の不足と、これを補うだけの処理系による自動最適化が現状の技術では困難なため、並列化の適用範囲が制限されることである。今後、HPFがペタフロップスマシンの言語インタフェースとなりうるためには、以下の要素技術を確立する必要があるだろう。
（a）プログラム記述能力の向上
（b）コンパイラ解析能力／最適化能力の向上
（c）実行時最適化技術
並列化においては、最適化の方法や、最適化のパラメータがデータサイズやループ長に依存することが多い。選択肢が2、3個の場合には、マルチバージョン方式といって、複数の最適化コードを生成しておき、実行時にこれらを選択実行する手法がとられるが、選択肢が多数あったり、複数のパラメータが相互にからみあう場合には、使えない。実行時にプログラムの最適化方法を決定できる枠組みの研究が必要である。
（d）階層構造の克服
ペタフロップスシステムが、仮に１万台以上の要素プロセッサから構成されるとすると、これらプロセッサが一様に１階層で構成されるとは考えにくい。クラスタなど、何らかの階層構造が採用されるのが普通である。この場合、並列化およびデータレイアウトについて、ユーザに階層を意識させない枠組みの研究が必要である。
（e）ツールの整備
ペタフロップスマシンになると、今より一層デバッグや性能チューニングが困難になると考えられる。これらの作業をシステマティックに支援する統合ツールの研究開発が重要である。
（3）パラダイムシフト
以上まで、ペタフロップスマシンが、現在の延長上で実現され、利用されるこを前提に、今後の課題、検討すべき要素技術について述べた。以下ではシステムの利用形態も含めて、起こりうるパラダイムシフトの可能性について大胆に論じてみる。
（a）異機種分散処理
LAN、WANなどのネットワーク技術の進展により、ペタフロップスマシンは、異機種分散システムとして実現される可能性がある。現在の大規模数値シミュレーションにおいても、主要計算部は計算サーバで実行し、結果の可視化やデータベース処理に専用システムを用いる場合がある。また、計算部分についても、マルチdisciplinaryコードなど、複数の計算スキームを扱うようなシミュレーションにおいて、適材適所のプロセッサを用いた異機種分散並列処理による高速処理が考えられる。このような場合には、異機種間での負荷分散、スケジューリングや、通信最適化技術の研究が重要であるとともに、異機種システム上での分散処理をユーザに意識させずに効率良く処理を行うフレームワークの確立が重要である。また、オブジェクト並列処理とデータ並列処理を融合するアプローチの研究も重要となるであろう。
（b）Reduced Programming Interface
ペタフロップスマシンにおいては、性能が出るパターンが非常に限られる可能性がある。このようなシステムの上でFortranやCのような、汎用の何でも記述できる言語を提供するのは実際的でないかもしれない。このような場合には、言語仕様として、性能のでるパターンだけをユーザに書かせられる枠組みの研究が大切である。言語の記述性は制限されるが、ユーザは、この言語に従う限り性能が保証されるのであれば、安心してプログラミングができる。この方向としては、Fortranのサブセットとして定義された、プログラミング言語F［7］という研究がある。
（c）ライブラリ指向プログラミング
上記と同じように、ペタフロップスマシンでは、高性能が得られる計算パターンが、かなり限られる可能性がある。この場合、性能の出るパターンをライブラリとして提供しておき、ユーザはこれの組み合わせにより、すべてのプログラミングを行うかもしれない。並列化や性能上プログラミングの困難な部分は、すべてライブラリの中に隠蔽できれば、ユーザはこれらに頭を煩わされることなくプログラミングが可能になる。ライブラリだけですべての問題を解決できる可能性は低いが、少なくとも現在のScaLapack [http://www.netlib.org/scalapack/]のような並列ライブラリインタフェースとその実現に関する研究は今後ますます重要になると考えられる。
これまで、並列処理における言語インタフェースの研究は、主にコンパイラ研究開発者を中心に行われてきた。しかしながら、今後の高性能計算機における言語処理技術を発展させるためには、コンパイラ開発者と計算機ユーザとが緊密に連携した研究活動が重要である。米国でMPIの標準化活動を推進したのは、主にユーザが主体であったし、最近では欧州でも
といった、ユーザと言語研究者が一体となったECのESPRITプロジェクトが発足している。今後は前節［2］で述べたような研究課題を両者が一体となって進めるプロジェクトを国策として実行すべきであると考える。
今後重要であると思われる技術調査項目について列挙する。
個人的には、この中で、実用コードの並列化例を可能な限り洗い出し、この中からペタフロップスマシンで性能が出ると思われる計算パターンを分類する作業が重要であると考える。
＜参考文献＞