プログラムの高速化・並列化サービスの事例

＊ここに掲載するのは、STFC Daresbury LaboratoryのA. R. Porter博士らによるHECToRレポート「WRF code Optimisation for Meso-scale Process Studies $WOMPS$ dCSE Project Report, A. R. Porter and M. Ashworth, STFC Daresbury Laboratory, A. Gadian and R. Burton, University of Leeds, P. Connolly, SEAES, University of Manchester, M. Bane, RCS, University of Manchester, June 2010」を要約したものです。

概要

このレポートは、HECToRのCray XT4における気象予報研究コード$Weather Research and Forecast model (WRF$)の性能改善に関する報告です。

WRFモデルは、National Center for Atmospheric Research $NCAR、米国大気研究センター$, National Oceanic and Atmospheric Administration $NOAA、米国海洋大気庁$, National Centers for Environmental Prediction（米国環境予測センター）, Air Force Weather Agency（米国空軍気象局）, Naval Research Laboratory（米国海軍研究試験所）, University of OklahomaおよびFederal Aviation Administration（米国連邦航空局）による共同プロジェクトで開発されました。
WRFは現在NOAAにおいて1-3日先の予報モデルとして利用され、世界の気象庁でも利用されています。2008年6月の時点で6000以上のユーザが登録されています。
WRFは、Advanced Research WRF $ARW$ソルバー（NCAR のメソスケール・マイクロスケール気象部門で開発）、および非静力学メソスケールソルバー（米国環境予測センターで開発）という2つのソルバーが統合されています。本プロジェクトではARWのみに関して議論します。
ARWは、圧縮性の非静力学オイラー方程式を、Arakawa-C型スタッガード格子による水平座標、および地形追従型乾静水圧の鉛直座標上を有限差分法で解きます。水平、鉛直共に空間離散化には2次から6次までの移流オプションを持ちます。時間積分は、2次あるいは3次のルンゲクッタ法、および音響/重力波モードにはより細かい時間刻みを用います。このモデルは、周期、開放、対称およびその他の側方境界条件をサポートし、polar Fourier filteringおよび周期的な東西境界条件を用いた全球シミュレーションが可能です。
さらに、設計当初から大規模並列コンピュータ上での実行を目的に設計されています。これはFortran90で記述され、ユーザは構築時に、MPIかハイブリッドOpenMP/MPIのどちらかを選択できます。

ここではARWコアを含むWRFバージョン3.1.1を使用しました。

使用したマシンはUK's national academic supercomputing serviceのHECToRです。ここでは、2009年に更新されたモデルであるフェーズ2a：各ノードはシングルおよびクアッドコアのAMD Opteron 2.3GHz Barcelonaを用いました。
更に比較のために、Swiss National Supercomputing centre $CSCS$のCray XT5である「Monte Rosa」マシンも利用しました。これは、6コアAMD Opteron 2.4 GHz Istanbulをノード当たり2つ持ちます。つまり、HECToRノードが4コアに対し、Rosaノードには12コアが装備されます。

ベンチマークデータ

このプロジェクトで行われたWRF実行の大半は、HECToRのUKコミュニティで用いられている代表的な構成である'Great North Run' $GNR$構成を用います。この構成は3種のネストした領域で定義され、相互に2種のフィードバックを持ちます。これは、高解像度$1Km$の小領域で覆われた北イングランドの気象予報のために設計されました。より広範囲かつより解像度が粗い外側領域は、北大西洋の大気の振舞いを捉えることが目的です。これを正方形でなく長方形としている理由は、その北側や南側の領域が最内側領域へ制限された影響しか及ぼさないためです。この構成は、NCARや教育ツール、英国で行われている科学フィールドキャンペーンにも使用されています。

シングルノード性能

·性能プロファイル

ここでは、PathScale3.2、PGI9.0.4、GNU4.4.2の各種コンパイラを用いてベンチマークを行いました。

MPIバージョンでは、PathScaleおよびPGIコンパイラによる性能はほぼ等しく、共にGNUコンパイラに勝ります。更に最適化オプションを様々に選んだ結果、PGIが最も高速でした。

ハイブリッドバージョンでは1MPIタスク当り4スレッドを用いました。512コアまではMPIモードとハイブリッドモードの性能差はほぼありませんが、これを超えるとハイブリッドが勝ります。これはMPIによる通信量の差です。この結果から、ハイブリッドモードはWRFに適していることが解ります。
HECToRとRosa上のMPIおよびハイブリッドのスケール性は良好で、ほぼ常にHECToRの方が優れています。例外はRosaにおいてノード当たり2MPIプロセスを用いたハイブリッドです。また、ハイブリッドモードはMPIモードよりも優れていました。

RosaよりもHECToRのほうが高性能である理由はというのは、WRFがメモリ帯域に対する需要が高いためです。つまりノード上のプロセス数を減らせば、MPI関数が費やす時間は削減されます。
キャッシュ使用率に対するハードウェアパフォーマンスカウンタの結果から、ノードでのユーザーコードで費やされた時間の削減について有用な情報が得られます。特に重要なのは、レベル1データキャッシュ（D1）のfillレートの増加ですが、実際のfill値はcpn（core per node）が減少するにつれて変化しないままです。 D1がデータをより迅速に受信しているという事実は、計算コアがメインメモリからデータを待つ時間が小さいことを意味します。 特にD1とD2のrefillレートのいずれも、cpnの数が減少するにつれて頭打ちを示しません。これは、メイン・メモリからのデータ検索がボトルネックのままであることを示します。

·キャッシュ効率の最適化

OpenMPあるいはOpenMP/MPIモードのどちらでコンパイルするかにより、モデルの領域分割のやり方が左右されます。分散メモリー$dm$モードの場合は、モデル領域はPE（即ちMPIプロセス）数を同等の矩形「パッチ」に分割され、各パッチは各PEに割当てられます。ハイブリッドモード$sm+dm$の場合は、パッチは更に複数の「タイル」へ分割されてOpenMPスレッド群で共有されます。
この分割はWRFにより自動で行えますが、パッチ当たりのタイル数やパッチグリッドの高さ/幅をユーザーが指定することも可能です。これはOpenMPを用いない場合でも可能です（この際は、一つのMPIプロセスが実行する最外側ループがタイル全体に渡るコード構造になります）。
実際にdmモードの計測結果は予想通り、PE数が少なく、パッチとその配列がキャッシュに収まり切れないほど大きい場合に効果があります。64PEで各16パッチを用いた場合は、最大20%の高速化が得られますが、1024PEでは各4パッチの場合には高速化は5%程度です。

並列性能

·プロファイリング

性能分析にはCrayPatとApprentice2を用いました。プロファイル結果からメモリー初期化が性能を劣化させていることが判りました。その他の物理計算ルーチンは良好なスケール性を持ちます。コンパイルフラグ'-DSGIALTIX'を外すことで性能は改善されました。

·領域分割

デフォルトではPE数nが与えられた場合、dmモードではnを因数分解してnxとnyを得るのに両者が出来る限りnの平方根に近い値が選ばれます。ここでnxとnyは、領域分割におけるプロセッサグリッドのそれぞれ水平及び鉛直次元数です。この数字はPEが動作するパッチの次元を決めることからシミュレーションの性能に大きな影響を与え、また、PEがハロデータを交換する境界長も決めます。ユーザは入力ネームリストでこれらの値を決めることが可能です。
ここで、256および504PEでその選択による影響を調べました。256の因数分解の数は限られていますが、デフォルトの分解の性能を約10％向上させるケース（8×32）があります。 パッチがはるかに小さい504個のPEでは、その効果はそれほど劇的ではありません。 これは、パッチの形状を変更すると、ハロ交換処理速度よりも計算速度に影響を与えることを示しています。

入出力性能

·プロファイリング

WRFは様々なI/OのAPIが使えますが、ここではシリアルおよび並列のnetCFDおよびpNetCFD[4]を用いました。用いたバージョンは3.6.2です。
GNR構成データでは3種の履歴ファイルが生成され、その内で最大のものは最大グリッド数を持つ領域3のものです。このデータは1.63GBです。
WRFが分散配列を出力するデフォルトのアプローチは、MPI_Gathervを用いて全てのデータをマスタPEに集め、配列を再構成して、シリアルnetCDFライブラリを使用してディスクに書き込む方法です。最終的には、ディスクに書き込まれたバイト数が全てのPEにブロードキャストされますが、これは、マスタが書き込みを完了するまで全てのPEがブロックされることを意味します。
出力時間はコア数に対して全くスケールしません。

·ストライピング性能

Cray XTは、並列I/OをハードウェアでサポートするLustre分散並列ファイルシステムを装備します。HECToRは72Object Storage Targets $OST$と、大規模ファイルのOSTへのストライピングをサポートします。
CrayPatによる分析から、WRFは一度に4MB単位で書込みをしていることが判りました。典型的にはMB当り１OSTを用いる事が推奨されていることから、4OSTが妥当と推測されます。しかしながら、各領域については0.5GBオーダーのデータ書き込みが発生し、これらは異なる変数から成っており、全て個別に出力されます。実際に、この構成データではコード内で160回のnatCFD呼出しが存在します。キャッシングを利用しなくては性能向上は図れないことは明らかです。
出力単位が小さい場合には、そのパフォーマンスはストライプサイズまたはOST数の影響を受けないことが確認されました。

·pNetCFD

WRFは、並列I / OをサポートするNetCDFライブラリの拡張版であるpNetCDFで実装されたI/O層を装備します。残念ながら、WRFはこのレイヤーを構築されたときに、全てのPEがそのデータの一部をディスクに書き込むように記述されています。大規模PE数では、各出力は比較的小さなデータであり、1つのファイルに多数の出力がアクセスして競合を引き起こす可能性があります。 実験により、単一フレームの履歴を書き出すまでの時間は、使用されているコア数にほぼ比例して増加していることが示されました。使用OST数（デフォルト値は4）を調整することでこのパフォーマンスを向上させることは可能かもしれませんが、大規模なPE数にはスケールしません。
従って、現状の実装がそうですが、各PEのメモリ量が単一の出力プロセスへのデータ収集に十分でない場合に、WRFのpNetCDFは最適です。

·非同期I/O

WRFは、入力ファイル内の指定により、実行時にI/O専用に割り当てるPEの数をユーザが選択できる機能がを持ちます。 このIOサーバ自体は、「ルート」IOサーバに書き込まれるフィールドを再構成します。このサーバは、シリアルWRF I/O機能の1つ（この場合はnetCDF）を使用してディスクに書き込みます。
IOサーバの導入に伴い、I / Oのボトルネックは実際のデータのディスクへの実際の送信ではなく、計算PEからIOサーバへのデータの収集となります（実際の書き込み時間は変更されませんが、計算PEの遅延が長くなります）。 WRFコードでは、各IOサーバはいくつかの計算PEに関連付けられ、これらのPEは一緒にMPIコミュニケータにマッピングされます。計算PEからIOサーバへのデータの収集は、このコミュニケータを介してMPI_Gathervを使用して実装されます。 WRFは、MPI_COMM_WORLDの最後のnIO PEがIOサーバとみなされ、計算PEがラウンドロビン方式でこれらのIOサーバに関連付けられるように実装されています。
デフォルトでは、Cray XTのMPIタスクはSMPスタイルの計算ノードにマップされます。その結果、WRF IOサーバはすべて一握りのノードにまとめられます。すべての計算PEがこのIOサーバのグループにデータを送信しなければならないことのは好ましくなく、この場合は大量のネットワーク競合が発生します。この状況は、MPIタスクのカスタムマッピングをノードに指定することによって改善することができるため、これを使用してIOサーバをノード間で均等に分散することを試みましたが、小規模のテストジョブと同様に、これらの考慮で得られる性能差は、IOサーバが無い場合からの性能向上と比較すれば大きくはありませんでした。

謝辞

このプロジェクトは、nAG Ltd.が運営するHECToRの分散計算科学および工学$CSE$サービスの基に実行されました。英国の国立スーパーコンピューティング・サービスである、HECToR：英国リサーチ・カウンシル・ハイエンド計算サービスは、リサーチ・カウンシルを代行するEPSRCが管理しています。そのミッションは英国学術界の科学および工学の研究支援です。HECToRスーパーコンピューターは、UoE HPCx Ltd.およびnAG Ltd.のCSEサポートサービスにより管理運営されています。
Swiss National Supercomputing Centre $CSCS$のMonte Rosa,Cray XT5へのアクセスに感謝いたします。
困難な問題に対する助力に関して、コード開発者の一人であるNCAR,John Michalakes博士に感謝いたします。

文献

[1]	The Swiss National Supercomputing Centre, http://www-users.cscs.ch/
[2]	HECToR - The UK Supercomputing Service, http://www.hector.ac.uk/
[3]	NetCDF, http://www.unidata.ucar.edu/software/netcdf/
[4]	J. Li, W. Liao, A. Choudhary, R. Ross, R. Thakur, W. Gropp, R. Latham, A. Siegel, B. Gallagher and M. Zingale, 'Parallel netCDF: A High-Performance Scientific I/O Interface' in Proceedings of Super Computing '03, November 2003.
[5]	IDV - the Integrated Data Viewer, http://www.unidata.ucar.edu/software/idv/