4. 高速化プログラミング事例

　ここでは、原研において高速化技術者が実際に行っている高速化作業の手順及び事例等を紹介する。

4.1　作業の流れ

　VPP500における高速化作業の進め方について説明する。

4.1.1　作業の分類

　ユーザより入手した原子力コードは、ユーザの要望に沿って作業を行うことになるが、使用状況等により表4.1のような作業分類を行う。

表4.1 作業の区分け

　解析規模を大きくする場合は、1PEのメモリでは実行不可能なため、メモリ分割による並列化が必然となる。一方、高速化の場合、原則的にコードの性質、運用上の条件を加味し、表4.1に準じて作業を行っている。これは、CPUの有効利用にも関係するものである。
　さらに、コードによってはベクトル化が困難な場合がある。このような場合には、原研で導入しているAP3000へのインストール、さらに並列化を行う場合もある。

4.1.2　作業手順

　コードを入手してからベクトル化・並列化までの一般的な手順を示す。

4.2　手法について

　ベクトル化・並列化を行うにあたり、その手法について以下にまとめる。

4.2.1　コード変更に関する注意

　ベクトル化・並列化のためにコードを変更することになるが、手法によっては、オリジナルのコードを大幅に変更することがある。一方、原研では高速化チューニングを施したコードに対して、後にユーザが（高速化とは無関係な）機能拡張等のための変更を加えることがある。このような場合、チューニングされたコードをユーザ自身が変更することは困難である。このため、作業前にユーザの確認を取り、高度チューニングの範囲を限定する場合がある。

4.2.2　並列化言語

　並列化を行う場合、VPP FORTRANと MPIのどちらかを使用することになる。原研では前述のとおり複数の並列計算機を所有しているため、VPP500以外でコードを実行する場合がある。このため、最近はMPIによって並列化を行う傾向が高い。

4.2.3　並列軸について

　ベクトル化、並列化を行っていく上で重要なポイントとなるのは、どの軸でベクトル化、または並列化をしていくかということである。特に並列化の場合、並列軸の選択次第で各PEの負荷分散や通信の発生に影響を与えるため、作業前に慎重な調査を要する。また、ベクトル軸との兼用をした場合、（ベクトル長が短くなることで）ベクトル性能の低下を招くことがあるので、なるべく避けるようにしている。

4.3　原研における原子力コードの高速化の例

表4.2 ベクトル並列化した原子力コードの概要

4.3.1　コード調査

　当該コードはCRAY計算機で開発されたため、基本的にベクトル処理できる構造になっている。また、2次元コードであり、ベクトル軸としてはX方向、もしくはY方向となる。
しかし、オリジナル版でのベクトル化状況はあまりよくない。当該コードのVPP500へのインストール時に、CRAY特有の組み込み関数（CVMGM）がVPP500では用意されていないため、これを模擬した外部関数を作成し代用している。このため、この関数はCRAY上ではベクトル化対象組み込み関数であったが、VPP500では一般の外部関数となり、この呼び出し部分はベクトル化対象外となってしまった。この他、細かい所でベクトル化されない要素を含んでいる。
　規模拡大のための並列化を検討した結果、このコードでは領域分割が有効であることが判明した。コード内で使用される配列（array）は、領域（メッシュ）に関するものが大部分であり、これを効果的に分割することで、解析対象の大規模化が実現できる。
　これらの結果、原則的にX方向をベクトル軸、Y方向を並列軸に採用することにした。

4.3.2　コスト分析

　CPUコスト分布を調査するため、SAMPLER及びANALYZERを実行した。SAMPLERは実際のVPP500上でのCPU分布を、ANALYZERは副プログラムの詳細な情報を得るためのものである。表4.3、表4.4にそれぞれの実行結果を示す。表4.3から分かるように、上位5ルーチンがコストの約98%を占めており、これらを高速化の対象とした。

表4.3 SAMPLERの結果（抜粋）

表4.4 ANALYZERの結果（抜粋）

sub1:	フォッカープランク方程式を解きながら粒子の物性値を解く。
sub2:	配列の操作を行う。
sub3:	ある計算ルーチンであるが、後にユーザのコード修正で廃止。
sub4:	フォッカープランク方程式解法ルーチンのひとつ。

4.3.3　ベクトル化

　当該コードにベクトル化チューニングを施した一例を以下に示す。
　前述したように、CRAY計算機で開発したコードが元になっているので、ベクトル化を意識したコーディングになっている（図4.1）。CRAY組み込み関数CVMGMを模擬した関数（図4.2）を、コンパイルオプションによるインライン展開をすることでベクトル化が実現できた（図4.3）。
　参考として、ベクトル化による性能向上率の測定結果を表4.5に示す。

図4.1 オリジナル版CVMGM引用部分

ここをクリックすると拡大されます

図4.2 CRAY組み込み関数CVMGMを模擬した関数

図4.3 コンパイラオプションによるインライン展開でベクトル化できた例

ここをクリックすると拡大されます

表4.5 ベクトル化版の性能（参考）

4.3.4　並列化

　当該コードにY方向の領域分割を行う並列化を施した一例を以下に示す。
　領域分割の概念を図4.4に示す。

図4.4　領域分割の概念

(1)メモリ分割
　領域の大きさに関連を持つ配列すべてに対し、分割を行う。Y方向で分割するが、ある物性値を持つ格子に関する配列においては、ある格子点におけるその値が、隣の位置の物性値の影響を受ける場合がある。このため、場所によってはPEをまたいで参照する場合があり、袖を持たせている。オリジナルの配列宣言文を図4.5に、袖を持たせて分割した配列宣言文を図4.6に示す。

図4.5　オリジナルの配列宣言の例

図4.6　分割した配列宣言の例

ここをクリックすると拡大されます

(2)命令の分割
　配列の分割に伴い、正しく並列処理が行えるよう命令に対しても分割を行う。
　一例として、図4.7に示したDOループを対象とし、その処理を分割し並列化したものを図4.8に示す。

図4.7　オリジナル版並列化対象ループの例

図4.8　並列化した例

ここをクリックすると拡大されます

4.3.5　ベクトル並列化版の性能

　ベクトル並列化版を使用して速度向上率、解析可能サイズの調査を行った。

(1)速度
　速度向上率についての測定結果を表4.6及び図4.9に示す。

表4.6　ベクトル並列化版速度性能

図4.9　ベクトル並列化版速度向上率

　並列化による台数効果は使用PEが多くなるにつれ低下する。これは、コード内で並列化不可部分があること、データ転送時間によるオーバーヘッド等が原因である。

(2)解析可能サイズ
　解析可能サイズについての測定結果を表4.7に示す。

表4.7 ベクトル並列化版解析可能サイズ

　解析可能サイズが台数分より大きくなっているのは、不要な配列の削除、配列の兼用のチューニングを行ったためである。

4.4　大規模計算

　大規模計算は

1)	メモリを多く使用することで解析対象を大きくするorメッシュを細かくする。
2)	高速化によって時間発展シミュレーションを長時間にわたって行うor時間ステップを小さくして詳細な解析を行う。

の２つに大別される。
　原研においても粒子（分子）系コードや流体系コードに関しては、速度、メモリの要求は年々高くなり、現状のVPP500ではパワー不足になりつつある。また、原子炉事故時等のシミュレーションを行う安全性コードに関しては、メモリはともかく速度を要求される場合が多く、より高速なCPUが望まれている。

4.5　高速化作業のまとめ

　原研における高速化作業において一番の長所は、高速化技術者が実際に使用するユーザと同じ原研内に常駐していることである。これは、

1)	高速化作業中にユーザと密に接触できることで、作業が比較的スムーズに進めやすい。
2)	コード納品後、コードの使い方、ユーザによるコード改良及び問題発生等において、高速化作業者が緻密なフォローができる。

という大きな利点がある。
　また、作業を行ったコードに対し、すべて報告書を作成・保存しており、これらの高速化のノウハウを蓄積することで、代々の作業者の参考となっている（詳細は5章）。
　しかしながら、問題点もいくつか存在する。コードをベクトル化・並列化する場合、コード内容を把握してから実施することが望ましい。原研においては、ごくまれにコードに関する資料等が無い場合がある。ユーザがコード内容について把握していれば、さほど問題にはならないが、ブラックボックス的に使用しているユーザもおり、コードの内容を理解していない場合がある。このような時においては、コード理解に長時間を要したり、表面的なチューニングしか行えない場合がある。
　次に高速化、大規模化に伴う問題点を述べる。これらの作業の結果、（時間発展シミュレーションの長時間化等により）ディスク上に書き出すファイル（計算結果）が極めて大きくなる場合がある（この計算結果は図形化や統計計算等に用いられる）。この場合、ファイルの書き出しに長時間を要する。VFL-FS（Very Fast and Large File System）を使用しても、格段に速くなるわけではない。コードがベクトル並列化により高速になっても、I/Oに多くの時間を費やしてはCPUの有効利用にはならない。改善が望まれる点である。