1. メンバー
教授 朴 泰祐 教授 高橋 大介 教授 建部 修見 准教授 川島 英之 助教 多田野 寛人 研究員 梅田 宏明 研究員 田中 昌宏
研究員 Mohamed Amin Jabri 研究員 松本 和也
学生 大学院生 17名、学類生 6名
2. 概要
本研究部門では、高性能計算システムアーキテクチャ、並列プログラミング環境、GPU 利用技術、並列数値処理の高速化研究、広域分散環境におけるデータ共有を中心とするグリ ッド計算技術等の研究を行っている。
3. 研究成果
【１】PEACH2基本システムソフトウェアの開発とNASPB-CGにおける評価（朴）
PEACH2の通信ドライバ及び制御方式についてAPI上でユーザがエラーを起こしにくいよ
うな変更とエラーハンドリングを行い、ユーザアプリケーションをより記述しやすくした。
また、この仕様をもと に、NAS Parallel Benchmarks の CG ベンチマークを GPU クラスタ
HA-PACS/TCA 上で 2 次元プロセスマッピング実装し、短メッセージ通信に強いという TCAの
特性を生かし性能を向上させた。
図 1-1 にベンチマークの中核となる conj_grad 関数の実行時間を、PEACH2 による実装
（TCA）とInfiniBand上のMPIによる実装（MPI）で比較した結果を示す。問題サイズ（CLASS）
は S, W, A, B の順で大きくなる。最大 16ノード（16 GPU）による評価では、CLASS=W 以上 でスケーラビリティが見え始め、CLASS=Bでは概ねスケールしている。2次元分割によって平 均メッセージ長が短くなり、CLASS=WまではTCAの性能が上回る。一方、strong scalability
が現れるCLASS=A以上では、メッセージ長が長くなるため、TCAの優位性が減り、MPIとの性
能差はほとんどなくなる。さらにCLASS=BではInfiniBandのレイテンシを隠す十分なメッセ ージ長が得られるため、ノード数が増えると性能が逆転する。平成26年度に行ったCG法の
- 149 -
1 次元分割アルゴリズムに比べると TCA の優位性は高まったが、より大きな問題サイズにお いても性能を維持できるよう、さらに工夫が必要であることがわかった。
図1-1 NASPB-CGの２次元マッピング実装における各クラス問題でのTCA実装とMPI/IB実装の conj_grad関数の実行時間比較
【2】 GPU間直接通信MPIライブラリGMPIの開発（朴）
従来のCUDAなどの典型的GPU環境を並列処理に展開する場合、MPI通信をGPUのカーネ ル実行と別途記述する必要があるが、MPI通信を能動的に行えるのはホストCPUのみであり、
このためCPU用のMPIプログラムをGPU並列化するためには、通信に挟まれた計算部分のGPU カーネル化を通信が発生するたびに行わなければならない。この切り分けコストは並列 GPU アプリケーションコーディングにおいて大きな制約となり、プログラミングの複雑さとデバ ッグの難しさにより、プログラムの生産性を大きく低下させる要因となっている。本研究テ ーマでは、この問題を解決するために、GPUのカーネルコード上で直接GMPI関数を呼び出せ る新しいフレームワークとしてGMPI (GPU-self MPI)を提案・実装した。
当然ながら、GPUは能動的デバイスではないため、内部から自由にInfiniBandのような 外部通信機構を呼び出すことはできない。このため、実際のMPI通信はホストCPUに依頼し、
GPU 側とホスト CPU の間で通信依頼と結果のリターンを司る通信チャネルを作成する。この 通信チャネルに通常の cudaMemcopy のような通常のメモリ参照関数を使うことはできない。
なぜならば、これらの関数はGPUからホストCPUに制御が戻っていることを仮定しているが、
GMPI では GPU はホスト CPU と並行して走り続けることを想定するからである。近年の CUDA 環境では、ホスト CPUのアドレス空間に GPUのアドレス空間をピンダウンし、ここを双方で 読み書きすることで、PCIeを介した仮想的な共有メモリ空間を作成することができる。そこ
- 150 -
で、ここに双方がアクセスする情報通信用のリングバッファを複数設け、互いにポーリング とアップデートを繰り返して必要な情報のやり取りを行う。図2-1にこの様子を示す。
図2-1 GMPIで用いるピンダウンメモリ領域を使ったGPU・ホスト間のリングバッファ
構造
ここで、ノード間MPI通信性能をできるだけ低下させないために、GMPIではこのリング
バッファを用いて全ての通信データをやり取りせず、GPU 対応 MPIがGDR 等の機能を使って 最高の性能で実際の MPI 通信が実現されるように設計した。つまり、リングバッファを使っ てやり取りされるのは MPI関数の引数や結果の状態だけであり、通信対象となる実データは GPU側メモリに置いたままで、実際のMPI関数にその参照を委ねる。
GMPIにおいては、(a) MPI関数を呼ぶたびにホストCPUに制御を戻す必要がないためオ ーバヘッドが削減される、(b) プログラムの書き換えを最小限の手間で行える、という２つ
のメリットがある。(b)については自明であるが、(a)が正しいかどうかは、上述のリングバ ッファ機構を通じたデータ交換の性能に大きく依存する。そこで、従来方式の MPI-GDR/IB (InfiniBand上のGDRを用いたMPI通信)とGMPIの基本通信性能を、pingpong通信を用いて 評価した。結果を図2-2に示す。ここで、MVAPICH2-GDRはGDRを用いたMPI本体の通信レイ テンシであるが、実際の通信前には必ず GPU側のメモリ読み書きが終了していることを保証 するために、GPU との同期を取らなければならない。そこで、この同期コストも含めた通信
レイテンシも測定した。これとGMPIによる通信性能の比較を行った結果、図に示されるよう に、メッセージ長が 4KB 程度までの短い場合は 10〜20%程度の性能差はあるが、これを超え るとほとんど性能低下はないことがわかった。よって、ある程度の長さのメッセージであれ ば、上記(b)のメリットが大きく活き、並列GPUプログラミングの生産性が向上すると期待さ れる。
- 151 -
図2-2 GDR付きMPIの直接実行とGMPIを用いた場合のpingpong性能評価
図2-3 Himeno Benchmark (SMALL)のGMPI性能評価
現在GMPIはまだ実装中で、MPIの全関数に対応していないが、NAS Parallel Benchmarks 等の基本ベンチマークを評価するための関数セットは実装されている。これを用いて、Himeno Benchmarkを 2ノードで実行した場合の評価結果を図 2-3 に示す。ここでは3 次元空間を2
ノードに分割する際、データの連続方向分割と非連続方向分割（ブロックストライド転送を 必要とする）の２通りの分割方法を比較した（問題サイズは SMALL）。結論として、どちら の分割方法でもGMPIの通信オーバヘッドは通常の CUDA+MPIに比べ大きいが、分割方法が連 続方向であった場合の差は相対的に小さく、通信時間全体でみると2 倍から3 倍の時間がか かっているが、総計算時間では 40〜20%程度の時間増加に収まっている。Himeno Benchmark は並列通信に比べ比較的計算量の小さい問題であるため、計算時間がより支配的なアプリケ ーションにおいては、さらに性能差が縮まり、GMPIによるプログラミングメリットが生きる と考えられる。なお、Himeno Benchmark におけるオリジナルコード（CUDA+MPI）は 1317 行 であるのに対し、GMPI 版では1210行と小さくなった。差はほぼ100 行で1割弱であるが、
- 152 -
それ以上にプログラミングの見通しがずっと良くなり、CPU+MPI のプログラムからの移植性
が極めて高くなる効果が期待される。今後はGMPI関数の種類の充実化を行い、オーバヘッド の削減を目指す。その上で、より本格的な大規模コードのGMPI化を行い、コード量比較と性 能比較を進めていく予定である。
なお、本研究は情報処理学会ACSI2016において発表され、Outstanding Research Award を受賞した。
【3】 PGAS言語向け通信ライブラリGASNetのGPU向け実装とTCA実装（朴）
GASNet は 米 国 LBNL (Lawrence Berkeley National Laboratory)で 開 発 さ れ た 、PGAS (Partitioned Global Address Space)モデル実装用の低レベル通信ライブラリである。分散 メモリ上でMPIよりも軽い通信を実現する。これまでGASNetはCPUにおける並列通信のみを 対象にしてきたが、現在、これをGPUクラスタに対応させる拡張がLBNLによって進められて いる。そこで我々は、LBNLのGASNet/GPU開発チームと共同研究を行い、先方がInfiniBand を対象として進めているリファレンス実装と並行し、これを TCA 機構にも用い、両者の性能 比較を行う研究を進めている。本研究により、今後本格化されると思われる GPU を対象とし たPGASモデル言語の実装にTCAを容易に用いることができるようになると見込んでいる。
TCA上のGASNet/GPU（以下、GASNet/TCA）の設計・実装は、前節で述べたGMPIに似てい る。GPU側から発生されるGASNet通信要求は、ホストCPUとGPUで共有されるピンダウンさ れたメモリ空間に実装されたリングバッファを通じ、GPU 側の通信リクエストをホスト CPU が受け取って TCA 通信によって実施し、その結果をまた逆向きのリングバッファで返す。た だし、GMPIではリクエストはそのままMPI通信に引き渡されていたのに対し、GASNet/TCAで はInfiniBandを対象としたGASNet/GPU（以下、GASNet/IB）で想定される基本プロトコルを TCAの限られたAPIで実装するため、より一層の工夫が必要である。
図3-1にGASNet/TCAにおけるGPUとホストCPUの間のリクエストを受け渡すパケット通 信機構の様子を示す。この機構を用い、図 3-2 に示す４つのデータ転送モードを実装した。
ここで注意すべき点は、GASNetにおいてはsegmentと呼ばれる連続アドレス空間を通信にお けるオブジェクトと定義しているが、現在のGASNet/GPUプロトタイプではこのsegmentを１ つだけ許していることである。並列GPU処理では当然、データは基本的にGPU上に存在して いると仮定するため、この1つだけのsegmentはGPUメモリ上に存在することになる。図3-2 の各通信モードはこれを意識している。