（様式 20）成果報告書

TSUBAME 共同利用 平成２８年度 学術利用 成果報告書

利用課題名 OpenACC による圧縮性流体解析プログラム UPACS の高速化に関する研究
利用課題責任者 星野哲也
所属 東京大学情報基盤センター

邦文抄録（300 字程度）
次世代のスーパーコンピュータにおいて主流になると考えられる，メニーコアプロセッサを用いた計算環境へのアプリケーションの対応が急務である.IHI が所有するアプリケーションである UPACS_turbo について，メニーコアプロセッサ向けの記述言語として注目されている OpenACC により並列化を行い，TSUBMAE2.5 の 1 GPUを用いた評価の結果，良好な結果を確認している.本課題では，単体の GPU 向けの最適化を行った上で，複数GPU を効率良く利用するための手法を開発し，実際の大規模なシミュレーションデータによる評価を行うことを目的とする.

Keywords: ５つ程度
OpenACC, GPU
背景と目的ればマルチコア CPU での並列実行が可能である．指

地震や気象予測，または航空機や高層ビルの設計な示文に対応していないコンパイラは指示文行をコメント

どにおいて，今でこそ一般的となった数値シミュレーショとして無視するため，元のソースコードを保全できる．

ンは，計算機の急速な性能向上の恩恵を受けることでしかし，OpenACC は 2011 年に発表された比較的新し発展してきた．しかし近年における計算環境の変化は，い 規 格 で あ り ，2015 年 10 月 に 新 し い 仕 様 で あ る

アプリケーションの利用者にとって必ずしも喜ばしいも

OpenACC2.5 が発表されたばかりの，未だ発展途上のではない．コア単体の性能向上が物理的な制約からのプログラミングモデルであるため，特に実アプリケー頭打ちになりつつある近年においては，計算機はコアションにおける評価が少ないのが現状である．の数を増やすことによって性能向上を続けているが，本稿では，実際に株式会社 IHI で利用されているアプ

多数のコアを効率良く利用するためには，往々にしてアリケーションである UPACS_turbo の OpenACC によルゴリズムの見直しや並列プログラムング言語を用いる高速化を行った.

た再実装が必要となるためである．またメニーコアプロ

UPACSセッサの登場など，実行デバイスの形態も多様化して本研究において対象としている圧縮性流体解析プログきており，数十万行にも及ぶアプリケーションをその都

ラム，UPACS について説明する．UPACS は独立行政度再実装することは現実的ではない．既存のアプリケ

法人宇宙航空研究開発機構 JAXA により研究開発さーション資源を活かしつつ，計算環境の変化に柔軟にれている，航空宇宙分野において要求される様々な流対応するための仕組みが求められている．

体現象の解析に用いることを目的とした，汎用的な流そこで，既存のアプリケーションの並列化手法として，コ体アプリケーションである．ただし，今回対象としている

ンパイラ指示文ベースのプログラミングモデルが注目さ

UPACS は，JAXA の UPACS をベースとして，株式会れている．マルチコア CPU 向けの並列プログラミング

社 IHI が開発のために独自の拡張を施したものであり，モデルである OpenMP や，メニーコアアクセラレータ向UPACS_turbo と呼称する．

けの OpenACC などがこれにあたる．指示文ベースのオリジナルの UPACS では圧縮性流体の数値シミュレプログラミングモデルは，基本的には既存のアプリケーーションを並列計算機上で行うために，マルチブロックションに対し数行の指示文を加えるだけであり，対応す構造格子法を用いている．マルチブロック構造格子法

るコンパイラが指示文を解釈し，例えば OpenMP であでは，複数の構造格子を非構造的に接続することで，（様式 20）成果報告書
複雑形状まわりの計算格子を作成し，各々の構造格子

Qt+1(x,y,z) = a1*Qt(x,y,z) + a2*Qt(x-1,y,z)

を 1 ブロック単位として MPI プロセスに割り当てること+ a3*Qt(x,y-1,z) + a4*Qt(x,y,z-1)

で，並列計算機上での実行を可能にしている．なお，+ a5*Qt(x+1,y,z) + a6*Q_t(x,y+1,z)

1MPI プロセスに複数のブロックを割り当てることは可+ a7*Qt(x,y,z+1)

能であるが，1 ブロックに複数の MPI プロセスを割り当てることはできない．またオリジナルの UPACS は，

図 1 陽解法

様々な流体解析プログラムを共通的に利用できるプラ

Qt+1(x,y,z) = a1*Qt(x,y,z) + a2*Qt+1(x-1,y,z)

ットフォームの確立を目的としているため，コードの階+ a3*Qt+1(x,y-1,z) + a4*Qt+1(x,y,z-1)

層化，データおよび計算手法のカプセル化といった，オ+ a5*Qt(x+1,y,z) + a6*Q_t(x,y+1,z)

ブジェクト指向的な考え方を用いて設計されている．こ+ a7*Qt(x,y,z+1)

れにより，数百ものモジュールを共通のデータ構造を用いて管理可能としている．

図 2 陰解法

以上については UPACS_turbo も共通であり，大きな枠組みは変わっていない．UPACS_turbo においては，翼列周りに発生する乱流を解析するための解法が追12378…

45622333加されているのが特徴であり，また計算精度をオリジナ	ルの倍精度から単精度に落としている．

結果および考察1

図 3以前までの OpenACC 実装では，陰解法部分がボトル1223ネックとなっていた．この部分の高速化のために
CUDA Fortran に よ る カ ー ネ ル 実 装 を 行 い ，

122333OpenACC 側から呼び出す実装方式を用いた. CUDA	

カーネルを使う場合，host_data ディレクティブを用いることで，OpenACC 側で生成されたデバイス上のデータ

図 4のポインタを CUDA カーネルに渡すことができる.

UPACS において用いられている陰解法の並列化手法

UPACS_turbo の陰解法部分について簡単に説明すである Hyper Plane 法(超平面法)は図 3 の右のようなる．まず陽解法とは，図 1 のように左辺 Qt+1 を更新す順番で解くことで，データの順序依存関係を保ちながらる際右辺項には Q_t しか現れない．故に同タイムステ並列化する手法である．しかしこの方法はメモリアクセップのにおいてデータ依存がないため並列性が高く，スが非連続になるため，一般的に性能が落ちる．

GPU などに向いている．一方図 2 のような陰解法は，そこで今回我々は，この Hyper Plane 法の高速化手

右辺に Qt+1 が現れる．故に，Qt+1(x,y,z)を計算する法として，図 4 のようなブロッキングを検討した．ブロッ

ためには Qt+1(x-1,y,z), Qt+1(x,y-1,z), Qt+1(x,y,z-1)

キングの際，例えば小ブロックを 32x1x1 のブロックとの計算が完了していなければならないため陽解法と比することで，ブロック内部での依存関係を X 方向のみに較して並列性が低く，GPU 向きではない．しかし陰解限定できる．これにより，Qt+1(x,y,z) を更新する際に，法は収束速度が早いため，アプリケーション全体でみ依存のある a2*Qt+1(x-1,y,z)$以外の点は各スレッドるとどちらが速いかは明らかではない．

が連続的読み込むことができるため，読み込みの局所性が高くなる．Qt+1(x,y,z) の更新と a2Qt+1(x-1,y,z)の読みは逐次で行う必要があるが，UPACS では係数
ai を計算するために多数の点にアクセスする必要があ（様式 20）成果報告書
るため，結果として高速化が可能である．適用の結果を図 5 に示す。

図 6

0.25"

Elapsed()me(/(1)me(step([sec]0.2"

図 7
0.15"
OpenACC"
CUDA"

0.1"

まとめ、今後の課題

当初の目的であった，大規模環境下でのロードバランシングなどは完了していないため，今後は大規模並列環境での高速化を目指す．

0.05"

0"
blocking"

blocking"	

図 5
この最適化により，CUDA 版においては 2.39 倍の高速化が得られているが，この手法は必ず同期を必要とするため，同期構文を持たない OpenACC では適用できない手法である．

また，今までの OpenACC 版 UPACS_turbo では，逐次実行部分が実行時間の大半を占めていることが問
題 だ っ た ． 原 因 は fortran の 組 み 込 み 関 数 で あ る
reshape が，OpenACC 対応コンパイラである PGI コンパイラでは非常に低速であったためである．その部分について最適化を施した．図 6 が最適化を施す前であり，図 7 は最適化適用語である．報告書のフォームが Word であるため図表の自由が効かず，見辛いと思うが，図 6 と図 7 はどちらも 2 タイムステップ分の実行時間を示しており，図 6 で空白の部分が CPU で実行されている部分であり，図 7 では空白部が明らかに少なくなっていることがわかる．また，本実験については
TSUBAME 環境ではなく，P100 GPU にておこなったものである．