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

＊ここに掲載するのは、STFC デアズベリー研究所のStephen M. PicklesおよびAndrew R. Porter両博士によるHECToRレポートDeveloping NEMO for Large Multi-core Scalar Systems:Final Report of the dCSE NEMO project, Stephen M. Pickles and Andrew R. Porter, STFC Daresbury Laboratory, July 2012」を要約したものです。

概要

このプロジェクトの目標は、海洋モデリングコードNEMO に対する、HECToRなどの最新の非常に大きなマルチコアスカラーシステム上でのコードのパフォーマンス向上、スケーラビリティ向上、使いやすさの向上です。具体的には以下の作業を行いました。

• 1.スカラープロセッサ上でより良いキャッシュ再利用のための3次元配列インデックスおよび関連するループネストの再順序付け。
• 2.マルチコア・アウェア・パーティショニング（MCA）と陸上での冗長計算の排除。

これらのうち、（1）は完了しましたが、（2）は部分的に完了しました。作業は12人月を費やしました。

背景

NEMO (Nucleus for a European Model of the Ocean) [1]は、英国とヨーロッパの海洋学コミュニティにとって戦略的に重要な海洋モデルコードです。
NEMOは、全球や海洋盆地への適用で長年にわたり成功裏に使用されていますが、棚海モデルとしての利用はあまり開発されていません。英国の海洋研究計画（Oceans 2025; http://www.oceans2025.org）の棚海モデリングパートナは、モデリング作業を海洋と連携させてMet Officeとの取り組みを調整し、海洋棚カップリング問題に取り組むために、Proudman Oceanographic Laboratory沿岸海洋モデルシステム（POLCOMS）[2]、[3]の使用から、棚海のモデル化にNEMOを使用へ変更することを決定しました。この決定を下すにあたり、彼らはNEMOに対してマルチスケール海洋学問題に対処するために多くの作業が必要であることを認識しました。特に浅海問題に使用されるアルゴリズムや、近代的なアーキテクチャー上の何千ものコア上でのコード性能やそのスケーラビリティが重要です。このプロジェクトは、POLCOMSで既に実証された技法をNEMOに適用することで、パフォーマンスとスケーラビリティの問題に対処するように準備されました。

·関連する作業

このプロジェクトは、以前のNEMOとPOLCOMSの作業に基づいています。前のdCSEプロジェクトでは、コンパイラオプション、netCDF 4.0圧縮の使用、陸地専用セルの除去について検討されました[4,5]。 GSUMプロジェクト[6]でのNEMOに関する作業と、GCOMSプロジェクト[3]のPOLCOMSパーティショニング手法[7]の改良により、ここで行われた作業プログラムの実行可能性が確立されました。 このプロジェクトと同時に実行されて最近完了したGNEMOプロジェクト[8]では、NEMOをGPUに移植する可能性について検討されました。
ハイブリッド OpenMP/MPI並列化（例えば、[9,10]参照）は、マルチコア共有メモリノードの汎用製品化に伴ってますます重要になってきており、このアプローチをNEMOに適用する初期の実験がCMCCで行われています[11]。 PRACE-2IPでは活動が拡大しており、[11]で採用されているアプローチの代替アプローチが検討されています。
NEMOにおけるI / O性能の問題は、コアNEMOプログラム内の非同期並列I / Oの開発によって対処されています。

·NEMOとPOLCOMSの比較

NEMOとPOLCOMSは共に有限差分法を用いた海洋モデリングコードです。これらは共にFortran言語で記述され、MPIを用いて並列化されています。またこれらは共に水平方向に領域を分割します。分割された矩形領域は一つのMPIプロセスが担当します。このモデルは、Fortran配列の2次元（2D）フィールドと3次元（3D）フィールドの両方を持ちます。これら配列はハロで宣言され、ハロのフィールド値は頻繁に交換されます。これは最隣接間の1対1通信で行われます。
これらの基本的な類似点にもかかわらず、NEMOとPOLCOMSはその起源が異なるために重要な違いがあります。NEMOは、深海コードのOPAの子孫でベクトルコンピュータ用に設計されています。 その後、NEMOの開発者は、ベクトル・アーキテクチャーに対するコードの親和性を保つことに努力してきました。一方、POLCOMSは沿岸および棚海のために設計され、早い段階でベクトルから超並列スカラアーキテクチャに移行しています[2]。
沿岸海域の典型的な領域は、湿った（海）と乾燥した（土地）の両方の地点を含みます。場合によってはグリッド点は、浸水の影響により湿潤状態と乾燥状態との間で振動することがあります。永久に乾燥したポイントで実行される計算は不要です。この冗長性を処理するのには2つ方法があり、一つは冗長な計算を実行して乾燥したポイントで結果をマスクするか、2つ目は冗長な計算を完全に排除する処理を行う、といったアプローチです。NEMOは前者のアプローチを採用しています。これは、各プロセッサコア上の計算量を不均衡にします。POLCOMSは後者のアプローチを採用し、各格子点でマスクを明示的にテストします。

·NEMOの領域分割、配列インデックスの順序付け、およびマスク

NEMOはその領域を同じ大きさの長方形のサブドメインに分割します。 バージョン3.3以前ではサブドメインのサイズはビルド時に固定されていました。前処理によって陸地に位置するサブドメインを排除することが可能ですが、これは実際の計算で常に利用されるわけではありません。
NEMOは3Dマスクを使用します。 地点（x、y）が乾燥している場所ではゼロで、海底の下でもゼロです（NEMOではアクティブレベルの数がグリッドポイントによって異なる可能性があります）。その他の地点では全て1です。それらはほぼすべての計算の最も内側のループで乗法的に適用されます。 この表現は冗長ですがベクトル・アーキテクチャに適しています。

·POLCOMSの領域分割、配列インデックスの順序付け、およびマスク

POLCOMSは、実行時にドメインをほぼ同数の湿潤ポイントを持つ長方形のサブドメインに分割することにより、計算負荷の不均衡の問題に対処します。これを行うには再帰的kセクション法[2]を使用します。著者らは最近、この方法を拡張し、複数のパーティションを並行して評価し、最良のパーティションを選択するようにしました[7]。この方法をマルチコア対応パーティショニングと呼ぶことにします。
NEMOとは対照的に、POLCOMSは最初にz-インデックスを持つ3D配列を定義します。したがってPOLCOMSでは、これはレイヤーではなく列であり、メモリ内で連続しています。スカラ・マシンでは、異なる配列からの複数の海水列が同時にキャッシュに収容される可能性が大きく、さらにメッセージバッファのパッキングおよびアンパックは連続したメモリブロックのコピーを伴うため、このレイアウトは3Dハロ交換操作に適しています。

POLCOMSはグリッドポイント(x,y)が乾燥しているか湿潤かに関する2Dマスクを用います。POLCOMS内では、グリッドポイント毎に1つのマスク検索というより小さなオーバーヘッドで、乾燥ポイントでの冗長な計算を避けることができます。

プロジェクト計画

著者らの研究[7]では、POLCOMSにおけるハロ交換処理の性能およびスケーラビリティに対する劇的な改善が、マルチコア対応パーティション化およびハロメッセージからの乾燥点の除去によって達成されることが示されています。このプロジェクトでは、同じ技術をNEMOに適用することを目指しました。
この提案は、国立海洋センター（NOC）、英国気象庁、およびNEMOシステムチームによってサポートされ、12人月が費やされました。プロジェクトの下記作業は18ヶ月間実行され、2012年6月に完了しました。目標は以下の通りです。

• 配列インデックスの再順序付け：すべての配列レイアウトをレベルインデックスが最初になるように変更し、関連するループを修正します。新しい順序z-firstと既存の順序z-lastを呼び出すようにします。
• HECToRなどの大規模なマルチコアシステムにおける、マルチコア対応パーティショニングとハロ交換の最適化。

項目１に優先度を与え、項目２は途中までで終了しました。
同じ会議では、3.3リリースに基づいたNEMOソースコードのブランチから作業を開始し、動的メモリ割り当てを追加することで合意しました。 以前にGSUMプロジェクト[6]にダイナミックメモリを割り当てたNEMOのバージョンを開発していたので、ダイナミックメモリ割り当てをNEMO 3.3に取り入れることにしました。 作成されたバージョンNEMO 3.3.1は2011年1月に公開されました。

作業内容と結果

·配列インデックスの再順序付けとループネストの最適化

新しい順序z-firstへのコードの膨大な修正を行いました。
初期プロファイリングでは、ランク0以外のMPIプロセスのメッセージ待機にかなり長い時間を費やす負荷の不均衡がありました。負荷不均衡の原因はREWINDで、ランタイムを10％増加させていました。 REWINDはLustreファイルシステムのメタデータカタログ処理に負荷を掛けます。そこで最初の例えば10ステップだけ毎回REWINDを実行し、それ以降は実行回数を削減させました 。
しかしながら、z-first順序ではループの依存関係によりベクトル化が困難である事が判明しました。その他のチューニングによりz-last順序コードと同等の性能まで回復しました。

·マルチコア対応パーティショニングとハロー交換パフォーマンスの最適化

GYREグリッド構成に対しては、以前に構築された領域分割[6]が直截的に適用可能です。よって、領域分割関連ルーチンと、ハロ交換ルーチンインターフェイスのみが修正対象です。
更に陸地が多いデータとして、UK Met Officeはバージョン3.4に含めるNEMOシステムに適切な構成を提供しました。このAMM12構成は標準リリースの一部であり、英国気象庁がサポートするという利点を持ちます。
AMM12の設定後、POLCOMSのマルチコア対応（MCA）パーティショニングコードを組み込むこみました。これは初期化ルーチンを少し変更するだけで済みましたが、 ハロメッセージから陸地ポイントを除くように通信ルーチンを拡張するにはやや多くの作業が必要でした。
テストとして、（MCAコードで列挙された）192MPIプロセスを用いた領域分解を13種作成しました。これら13の異なる分解に関してハロ交換の性能はほぼ2倍変化しています。この結果から最良の領域分割を選択することが可能です。

·結果

NEMOの配列インデックスを再順序付けする目的は、陸地上の不要な計算を排除することでした。残念ながら、配列参照とループネストを並べ替えるために必要な労力は予想以上に大きく、NEMOソースの変更は不十分なまま時間切れで一旦終了しました。

謝辞

このプロジェクトは、nAG Ltd.が運営するHECToRの分散計算科学および工学(CSE)サービスの基に実行されました。英国の国立スーパーコンピューティング・サービスである、HECToR：英国リサーチ・カウンシル・ハイエンド計算サービスは、リサーチ・カウンシルを代行するEPSRCが管理しています。そのミッションは英国学術界の科学および工学の研究支援です。HECToRスーパーコンピューターは、UoE HPCx Ltd.およびnAG Ltd.のCSEサポートサービスにより管理運営されています。

文献

[1]	G. Madec, "NEMO ocean engine", 2008, Note du Pole de mod?lisation, Institut Pierre-Simon Laplace (IPSL), France, No 27 ISSN No 1288-1619.
[2]	M. Ashworth, J.T. Holt and R. Proctor, "Optimization of the POLCOMS hydrodynamic code for terascale high-performance computers", Proceedings of the 18th International Parallel & Distributed Processing Symposium, Sante Fe, New Mexico, 26-30 Apr 2004.
[3]	Jason Holt, James Harle, Roger Proctor, Sylvain Michel, Mike Ashworth, Crispian Batstone, Icarus Allen, Robert Holmes, Tim Smyth, Keith Haines, Dan Bretherton, Gregory Smith, "Modelling the Global Coastal-Ocean", Phil. Trans. R. Soc. A, March 13, 2009 367:939-951; doi:10.1098/rsta.2008.0210
[4]	Fiona Reid, NEMO on HECToR - A dCSE Project, 4th May 2009, HECToR web site, http://www.hector.ac.uk/cse/distributedcse/reports/nemo/nemo_final_report.pdf.
[5]	Fiona J. L. Reid, "The NEMO Ocean Modelling Code: A Case Study", Proceedings of the Cray User Group, Edinburgh, 2010.
[6]	M. Ashworth and A. Porter, "Towards Generic Scaling of NEMO, the oceanographic component of the Unified Model", Final Report for the GSUM project, 2009.
[7]	Stephen Pickles, "Multi-Core Aware Performance Optimization of Halo Exchanges in Ocean Simulations", Proceedings of the Cray User Group, Edinburgh, 2010.
[8]	A. R. Porter, S. M. Pickles, M. Ashworth, "Final report for the gNEMO project: porting the oceanographic model NEMO to run on many-core devices", Daresbury Laboratory Technical Reports, DL-TR-2012-001 (2012).
[9]	L. Smith and M. Bull, "Development of mixed mode MPI / OpenMP applications", Scientific Programming, Vol. 9, No 2-3, 2001, 83-98.
[10]	M.A. Pettipher and M. Ashworth, "Converting MPI Codes to Hybrid MPI/OpenMP", Daresbury Laboratory Technical Report 2009.
[11]	Italo Epicoco, Silvia Mocavero, and Giovanni Aloisio, "NEMO-Med: Optimization and Improvement of Scalability", CMCC Research Paper No. 96, 2011.
[12]	Stephen Booth, "FTRANS User Guide", 1996.