3.2.3 並列プログラミング支援ツールの動向と並列システムの将来 妹尾義樹 委員
おそらくは、数万台規模以上の並列システムになるであろうペタフロップスマシンの性能を十分に活用するアプリケーションプログラムの開発は、非常に困難な作業になることが予想される。本節では、この超並列プログラミング作業を支援するツールについて、その要件と現状を米国を中心に行われているPTOOLコンソーシアム[1]の活動を例として参照しながら論ずる。また、このようなツール開発が並列システムの将来に与えるインパクトについて考察する。
3.2.3.1 並列プログラミング支援ツールの重要性と問題点
並列プログラミング[1]において、MPI[2]、HPF[3]そしてOpenMP[4]などの並列化記述インタフェースが重要であるのはもちろんであるが、並列プログラミングツールもこれらと同様に大きな役割が期待される。コンパイラによる自動並列化のみによって利用者が期待する並列性能が得られることが少ない現状では、プログラマが明示的に並列化の記述を行ったり、チューニングを行う必要がある。並列プログラミングの作業は逐次の場合のそれに比べて非常にプログラマへの負担が大きいからである。並列マシン（特に分散メモリの高並列システム）が実用システムとして、なかなか一般ユーザに普及しない原因として、MPIは低レベルすぎて一般プログラマが使いこなすのは困難であるとか、HPFは利用範囲が狭く、またコンパイラの安定性に問題があるなどの種々の要因があるが、並列プログラミングツールが未整備であることも大きな要因となっている。並列プログラミング種々のフェーズにおけるユーザの負担と期待されるツール機能について現在利用可能なツールと対比しながら考えてみる。
(1) 並列プログラム開発（コーディング）
対象となる並列システムのアーキテクチャや用いる並列化記述インタフェースにより違いはあるが、一般に並列プログラミング（ここでは逐次プログラムの並列化を念頭におく）においては、並列アルゴリズムの選択、データの分割（分散メモリへのデータレイアウト）、処理分割（ループ繰り返しや手続き処理などのプロセッサへの割り当て）、同期/通信の挿入などを考える必要がある。これらの作業は、対象となるプログラム構造および対象並列システムへの深い理解が不可欠であり、専門化にとっても複雑で困難な作業である。
一方で、自動並列化コンパイラやHPFコンパイラは、これらの並列化作業を自動的に行うが、その完成度はいわば幼稚園児なみといわざるを得ない。ただし、どのような並列化を行うかの指示さえあれば、プログラムの定型変換を自動的に処理でき、利用者の負荷を大きく軽減できる。そこで、これらのコンパイラ機能にユーザと対話できるインタフェースを設けインタラクティブな並列化支援ツールを構築することが重要である。データパラレル並列化支援として、FORGExplorer[5]、プログラム構造変換のForesys[6]などがある。
ただし、並列化作業の下流工程（ループリストラクチャリングやデータマッピング、計算マッピングの決定など）の作業のツールによる支援は実現可能性が高いと思われるが、最も困難な上流工程（アルゴリズムの選択、データ構造の選択など）についての支援については、まだ明確な筋道が見えていない。今後の重要な研究課題の一つである。
(2)チューニング
並列化作業において、作成した並列プログラムが一度で所望の性能を達成することはほとんどない。通常は、利用者がプログラムの並列実行の様子をなんらかのプロファイリングにより把握し、並列実行のボトルネックを一つずつ解消していくということになる。通信量の削減、通信の効率化、逐次実行部分の削減、負荷分散などが主な作業である。現在の並列システムでは、独Pallas社のVampir[7]（図3.2.3.1参照）、米PGI社のPGPROF[8]、イリノイ大のPablo[9] などのプロファイリングツールがサポートされており、プログラム中の負荷の分布や、通信の様子などを知ることができる。しかしこれらの情報からボトルネックの要因を判断したり、ソースコードの修正に結びつけるなどの支援はない。これらはすべてユーザの仕事となる。このユーザの作業を支援するツールの研究開発が求められる。
図3.2.3.1 Vampirの表示例
(http://www.pallas.de/pages/vampir.htmから引用)
上から2つ目のWindowで複数プロセスの実行履歴（Timeline表示と呼ばれる）を表示している。この中の矢印は通信を示し、これをクリックすることで通信内容や、対応するプログラム個所を表示できる（すぐ下、左下のWindow）。またその時点での全プロセスの通信の様子（右下）やプログラム全体の要因別コスト分布（一番下）が表示できる。
(3)デバッグ
並列プログラムのデバッグは、並列化の作業の中で最も困難であると言われている。複数プロセッサによる複数の処理の流れを追う必要があり、また同期忘れなどによるバグには再現性に乏しいものがあり、たとえば100回の実行で1回発生するエラーなども存在するからである。また、100プロセッサ以上の高並列システムにおいては、複数の処理の流れを追うことすら現実的でないケースもある。また、自動並列化コンパイラやHPFは、大規模なプログラム変形を行うため（コンパイラがワーク変数を導入したり、新たに手続きを生成したりする）、入力プログラムとオブジェクトコードの対応をとるのが困難で、ユーザが記述したプログラムレベルでのデバッグに制限が生ずるという問題点もある。デバッガは、OSやハードウェアに依存する部分が多いため、通常はハードウェアごとに、これを製品化しているベンダからサポートされることが多いが、最近では、米ETNUS社のTotalView[10]が多くの米国ASCIの高並列システムなど広範なプラットフォームでサポートされ、標準の並列デバッガとしての地位を確保しつつある。TotalViewは、マルチスレッドプログラムを対象とするグラフィックインタフェースのシンボリックデバッガでありで最小のキーストロークでデバッグ作業を行えるようインタフェースが設計されている。
(4)その他
実際の並列プログラミングにおいて、上記のそれぞれのフェーズ(作業)は独立に行われることは稀であり、相互に密接な関連を持っている。しかしながら、現在利用可能なツールは、特定機能に限定されたものが独立に存在するだけで、プログラマは、インタフェースの異なったこれらツールを使い分けながら、プログラミング作業を進める必要がある。場合によっては、これらツールがそれぞれ別のソフトウェアベンダから提供されることも稀ではない。たとえば、デバッガはTotal View、動的性能プロファイラはVampirという具合である。これらツールを統合し、たとえば、プログラム構造の解析ツールを参照しながらデバッグ、チューニングを行ったり、さらに、これら作業と並行してプログラム修正、再コンパイル、実行などを行える枠組みの構築が望まれる。
また、ツールインタフェースの標準化についてはほとんど未整備といってよい状況であり、対象となる並列システムが変われば、それぞれ別のツールインタフェースを習得する必要があるという問題点がある。
3.2.3.2 PTOOLコンソーシアム[11]
PTOOLコンソーシアム（ The Parallel Tools Consortium ）は、1993年11月に設立された米国の産、官、学を中心とするコンソーシアムで、Dept. of Computer Science, Oregon State UniversityのCherri M. Pancakeをリーダとして、並列化ツールの標準化、開発、普及を目的として活動を続けている。本コンソーシアムの最大の特徴は、活動がツール開発サイドのメンバよりもむしろツールを利用する側の研究者を中心として行われている点である。このことにより、ツール開発側のシーズに基づく論理ではなく、並列プログラムを実際に開発する経験から導かれた並列化ツールに対するニーズが検討され、活動の成果がより直接的に利用者にフィードバックされる結果に結びついている。以下で、PTOOLの主要な活動について述べる。
(1) ツールに関する要件の洗い出しと、インタフェース標準化
本活動は、PTOOLとNational Coordination Office for Computing, Information, and Communication.が支援するTask Force on Requirements for HPC Software and Tools[12]として行われ、スポンサーは米国ARPA、DOE、NASA、NSF、DODである。まず、ツールの要件がユーザを中心としてまとめられ、これがPTOOLのベンダメンバに提示され、実現可能性について議論される。ここで実現可能と判断されたそれぞれの要件は標準インタフェースとともに文書化され、計算機導入の際の要求仕様としての利用が推奨される。たくさんの主要ユーザから、ここでまとめられた要求仕様が用いられることにより、ツールインタフェースのデファクト標準の確立を目指している。要求されるべき機能は、それぞれの重要度に応じて、Essential for ALL users/ Essential for MANY users/ Essential for SOME users/ will be essential in the futureの4段階に分類されている。
ツールという枠組みで検討されているが、エディタやUnixコマンド、言語インタフェース、OSインタフェース、通信ライブラリ、数学ライブラリ、グラフィックス関連とユーザとHPCシステムとの接点となる機能はすべて盛り込まれている。、これらはASCIプロジェクト[13]での採用も考慮されており、標準化されれば、そのインパクトは非常に大きい。
(2) Lightweight Corefile Browser（終了済みプロジェクト）
並列プログラムの異常終了時に、その原因とプログラムソース上の発生個所、異常終了を引き起こしたプロセッサなどの情報を収集するためのツールとそのインタフェース。具体的には、LCF（Standardized Lightweight Corefile Format）と呼ばれる、異常終了時に出力するCoreファイルのフォーマット、Coreファイル生成のAPI、Coreファイルから必要な情報の取り出し方（グラフィックベースおよびキャラクタ端末ベース）が規定されている。また、本仕様に基づく試作ツールのソースコードが公開されており、ベンダが開発時にこれを用いることができる。
図3.2.3.2にグラフィックインタフェースによる表示例を示す。
図3.2.3.2 Lightweight Corefile Browserの表示例
異常終了時の複数プロセスの制御がどこにあったかを手続きのInvocation Tree上で示している。制御があった手続きが、そこにいたスレッドの数に応じて色分けして表示される。（http://www.ptools.org/projects/lcb/demo/ から引用）
(3) Parallel Print Function（終了済みプロジェクト）
MPIを利用した並列プログラムにおいて、並列に動作するプロセッサ（プロセス）の協調動作を記述できる出力文のインタフェースを提供。
たとえば、PPF_printという関数インタフェースが用意されており、これを用いて／各プロセッサが非同期に実行する／プロセッサのMPIでのrank順に出力する／指定した特定のプロセッサだけが実行する／出力をマージして特定のプロセッサだけが実行する／などの出力制御を行うことができる。
(4) Performance API
並列プログラムのチューニング作業には、並列実行の実行時情報（CPU時間、キャッシュミス、データ転送時間…）の把握が不可欠である。この実行時情報の取得インタフェースを定義するのがこのプロジェクトの目的である。取得情報としては、キャッシュミス関連、分岐予測情報、MIPS値、FLOPS値、実行命令数、クロックカウンタ値などがある。
(5) Dynamic Probe Class Library
並列プログラムのInstrumentationについて実行時にON/OFFができることを特徴とするモニタリングツールのAPIを定義する。インタフェースはモニタリングdaemonにサービスを要求するためのクラスライブラリとして定義されており、軽量かつflexible、そしてマシン不依存になっている。
(6) Portable Timing Routines
経過時間やCPU時間などを可能な限り低オーバヘッドで計測するタイマルーチンのAPIを定義している。ハードウェアで用意したタイマレジスタを読み出すだけの機能から、タイマレジスタ長の桁溢れを考慮して正しい時間を返すものまで種々の機能が用意されている。
(7) Message Queue Manager (MQM)
主に分散メモリマシンにおけるプロセッサ間通信を低レベルでコントロールするインタフェースを提供する。デバッグ時の利用を想定しており、通常のデバッガが変数の値を参照したりセットしたりできる機能をメッセージバッファ(Message Queue)のデータに対して行えるようにすることを目的としている。
図3.2.3.3 Message Queue Managerの表示例(次ページへ)
（http://www.ptools.org/projects/mqm/overview.html より引用）
中央のそれぞれの四角は各プロセッサのメッセージバッファを示し、キューにたまっているメッセージの数で色分けされている。メッセージタイプや送信プロセスなど、種々の情報によりフィルタリングすることができる。またそれぞれの四角をクリックすることによりキューの中身のデータを表示することができる。
(8) Memory Utilization Tracking Tool (MUTT)
並列プログラムのメモリ利用情報を得るためのインタフェース（API）の定義を目的としている。並列処理においては、コンパイラ、OS、ランタイムライブラリなどがそれぞれ複雑にメモリを利用するため、ユーザが実行時のメモリ利用を把握するのが困難である。このプロジェクトでは、プログラムからこれらの情報を得るためのAPIおよび、採取したモニタリング情報を可視化するインタフェースの構築を目標として活動している。
(9) Distributed Array Query and Visualization
並列処理において大規模な配列をプロセッサに分散配置して処理した場合に、利用者がその配列のグローバルなデータ内容を把握することが困難となる。これは、一般に配列が大規模であることと、たとえばMPIで記述されたプログラムの場合、物理的にあるまとまった意味を持つ配列データ（逐次プログラムなら1つの配列で宣言される）を分割し、このそれぞれを各プロセッサがローカルアドレスイメージで参照するためである。このようなケースにおいて、HPFで行われるような、グローバルイメージのデータの分散配置をユーザが定義し、この情報に基づいて、ツールにローカルイメージのデータをグローバルイメージでアクセスする機能を提供することを狙っている。また、大規模データを生データの羅列ではなく、グラフィックイメージによる表示機能の標準APIの検討を行っている。
図3.2.3.4 DAQVシステムの構成例
（http://www.cs.uoregon.edu/research/paracomp/proj/asci/daqv/overview/より引用）
一番下の各プロセッサにおいてMPIなどで利用される分散配列（ローカルイメージ）の全体構造をDAQV Masterで管理し、グローバルイメージでのClientからのデータ可視化要求に答える。
(10) High Performance Debugging Forum （http://www.ptools.org/hpdf/）
このForumは、直接のPTOOLプロジェクトではなく、PTOOLがスポンサーとなる活動と位置付けられている。活動の目的は、並列デバッガの標準インタフェースを構築することである。インタフェースとして、CUI（Character User Interface）ベースのものと、GUIベースのものと両方の標準化を目指している。
具体的活動としては、Conceptual model for parallel debugging、General Interface、Program Location Information、File/Function/Variable Names、Expressions and Language Compatibility、Process/Thread Groups、Data Display and Manipulation、Actionpoints、Process Control、Process Initialization and Destructionの10のWorking Groupsを設け、それぞれのWGにおいてユーザからの要求をベースにインタフェース案が構築されている。
現在のところ、CUIベースの標準インタフェースのドラフトが作成され、参加者でレビューするとともに、Reference Implementationが行われている。これは完成すれば公開し、ベンダによる本仕様に基づくデバッガの早期開発を加速することを狙っている。
(11) Parallel Unix Commands
対象とする並列システムの各プロセッサに並列にUnixコマンドを適用するインタフェースの検討を行っている。たとえば、それぞれのプロセッサがローカルディスクを持ち、あるディスクの内容を他の複数のディスクにコピーしたいような場合、このような処理を1つのコマンドで記述できると便利がよい。また、この処理において、１つのプロセッサが順次コピー操作を逐次的に行ったのでは効率が悪く、できれば、メッセージパッシングのブロードキャストのように、2分木方式で並列にコピー操作を行いたい。そこで、並列Unixコマンドの検討ということになったわけである。ファイル操作の他に、各プロセッサのプロセスやスレッドの状況を表示する機能なども検討されている。
3.2.3.3 並列プログラミング支援ツールで今後取り組むべき課題
並列プログラミングインタフェースについて、現状およびその問題点、そして米国PTOOLSの検討状況について述べてきたが、これらを踏まえて、今後わが国で取り組むべき課題について私見を述べる。
(1) インタフェース標準化
米国のここ数年のHPC分野での活動を振り返ると、標準化活動に非常に大きなウェイトをおいていることがわかる。たとえば、並列化インタフェースでは、MPIやHPFそしてOpenMPなどの仕様標準化を行ってきたし、ここで取り上げたPTOOLSコンソーシアムの活動の最大の目的もツールの標準インタフェースの構築にある。この他、Internet2プロジェクトにおける広域分散処理研究などでも標準インタフェースの構築が重要なテーマとなっている。
これら、標準化を目指す活動の共通の特徴は、
(a) エンドユーザ、官／学の研究者、ベンダなど広範な人々が参加するフォーラム形式で活動
(b) 活動を牽引するのは、官／学の研究者
(c) 国が資金面でバックアップするが、活動そのものは世界にオープン
(d) 官／学でリファレンスインプリメントを行い、ベンダ（SWベンチャーが多い）
の製品開発を加速（ある意味で新規産業の育成につながっている）
などである。これに対し、日本では標準化を意識した、こういったタイプのプロジェクトがあまりにも少ないように思われる。今後の大規模プロジェクトでは、テーマにかかわらず、技術の核となるべき標準インタフェースの構築をフラグシップにすることが重要だと考える。
(2) HPCユーザ層の拡大
PTOOLSの活動は、ある意味では非常に泥臭いものである。華やかな新規技術を追求するのではなく、既存技術に立脚した地道なインタフェースを構築している。たとえば、Lightweight Corefile Browser やParallel Print Function、そしてPortable timing Routinesなどがその典型である。これらは非常に地味ではあるが、一方で標準化が実現されれば、HPCユーザにとっては大きな利益になるものである。 技術的に新鮮味が薄くとも、先端の現場で毎日HPCシステムと格闘している多数ユーザからの要望をもとにしたインタフェースを構築することで、自らが使ったことのないベンダ任せのシステムよりも、はるかに使い勝手のよいものができあがる。そして、これらツールの整備により、HPCユーザ層を拡大することができる。
また、これらの活動形態にはもう一つの利点がある。すなわち、ユーザとベンダが、利用インタフェースに関する議論をすることにより、ベンダにはユーザの立場の情報が、またユーザにはベンダのインプリメントにかかわる技術情報が双方向に流れる。ユーザはシステムについてのより深い知識を吸収することにより、システム利用技術を高めることができる。この点で、ツールインタフェースというのは非常に良い切り口である。HWアーキテクチャに対して注文をつけるのはデバイステクノロジに関する知識も必要であり、かなり難しいが、いつも使っているツールに関する問題点はユーザが一番良く知っている。
HPC分野でのわが国の最大の問題点はユーザ層の薄さにある。一部先端ユーザは存在するが、その絶対数および裾野が小さい。特に、HPCシステム構築技術に精通したエンドユーザが欧米に比べて少ないように思う。このため、ユーザからベンダへの注文が少なく、Seeds指向あるいは欧米発祥のツールを押し付けられることになる。インタフェース標準化をフラグシップとした産官学が一体となったプロジェクトにより、ユーザ層の拡大を目指すことは重要であると考える。米国のあと追いになるからと、これら活動を眺めているばかりだと、米国との差は広がる一方である。
(3) ペタフロップスマシンにおけるツール整備
ペタフロップスマシンを実現したとして、この上でどのようなツールが必要になるかについてあらためて考えてみると、実は良くわからないというのが実情である。米国の活動も、ASCIなどを視野においているが、どちらかといえば、市場の大きい中並列のSMPが主対象であるように思える（特にベンダの興味はここに集中している）。HPCシステム（特にペタフロップスマシンのようなハイエンド機）ではハードウェアはできるだけシンプルな作りにして、その性能を追求する。複雑なことは、可能な限りソフトウェアに任せるというのが今後の流れのように思う。ペタフロップスマシンを目指すプロジェクトを考えるなら、システムソフトウェア、特にツールの研究開発にもある程度のウェイトをおいたものにする必要がある。
参考文献（URL）