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

＊ここに掲載するのは、エジンバラ大学EPCCのFiona J. L. Reid博士によるHECToRレポート「NEMO on HECToR A dCSE Project, Fiona J. L. Reid, EPCC, The University of Edinburgh, May 4, 2009」を要約したものです。

概要

このプロジェクトの目的は、海洋モデリングコードNEMO[1]のI/O性能とネストモデルの性能改善の可能性を調査することです。プロジェクトは2008年5月から2009年4月まで行われ、National Oceanographic Centre, Southampton $NOCS$のAndrew Coward博士が中心となり、nAGのChris Armstrong博士がそのサポートを行いました。作業内容は、NEMOのI/O性能の改善と、NEMOのネストモデルの調査と改善です。

現状のNEMOのI/Oのやり方は、大規模プロセッサシステム向けではありません。研究者はより高い空間解像度でより複雑なモデルを用いる方向に向かっているため大規模プロセッサシステムが要求されています。このためI/Oボトルネック問題の解決が必要です。ここではNEMOのI/O性能とスケール性を調査し、NEMOのモデル内に適切な圧縮アルゴリズムを用いた改善を行います。

NEMOは、全球モデルに異なる海洋部分に異なる解像度を割り当てるnested model（入れ子モデル）を用います。例えば、太平洋に1度解像度、残りの海洋には2度解像度でモデル化します。このタイプのモデルは、計算コストを抑えつつ注目する海洋の性質をより詳しく調べることができます。過去においては、こうしたモデル準備には多くの時間が掛るため、HPCシステムにおいては今と比べて多くの計算は困難でした。ここでは、こうしたnested modelの性能を調査し、スケーラビリティを持つ安定かつ最適化されたnested model性能の実現を目指します。

NEMOの概要

NEMO $Nucleus for European Modelling of the Ocean$は、海洋学研究と運用海洋学のためのモデリングフレームワークです。このフレームワークは、海氷、生物化学、海洋運動学、トレーサー等の様々な部品の個別実行やこれらの連携動作を可能にしています[1]。
現状のNEMOは3つの部品で構成され、（海氷以外は）スタンドアローンモデルとして実行可能です。この3部品は以下のものです：

1. OPA9：OPA海洋モデルの新しいバージョン、FORTRAN90
2. LIM2：Louvain-la-Neuve sea-ice model海氷モデル、FORTRAN90
3. TOP1：輸送コンポーネントベースのOPA9移流拡散方程式$TRP$およびLOBSTERとPISCESの2成分を含む生物地球化学モデル

この報告ではOPA9コンポーネントに焦点を絞り、National Oceanography Centre, Southampton $NOCS$で修正されたNEMOバージョンを用います。NEMOのNOCS版は基本的にはリリース版です。NEMOに関しては、作業中に更新があったためバージョン2.3と3.0について議論します。

HECToRシステムの概要

HECToRは英国大学研究者が利用可能な新しいハイエンド計算リソースです。HECToR Cray XT5システムは2007年10月にサービスインし、スカラーシステム$XT4$およびベクトルシステム$X2$で構成されます。このプロジェクトではスカラーのみを用います。

アーキテクチャ：
XT4は1416計算ブレードで構成され、其々に4デュアルプロセッサソケットが搭載されています。総数11,328個のコアを独立にアクセス可能です。一つのデュアルコアプロセッサのソケットがノードと呼ばれます。このプロセッサはAMD社の2.8 GHz Opteronです。各デュアルコアノードは6GBメモリーを共有しています。システムの理論ピーク性能は59Topsです。AMD Opteronコアは一つの浮動小数点加算および乗算ユニットを持ち、これらは独立かつ並列に動作します。サイクルあたり一つの単精度の浮動小数点加算および乗算演算を実行するため、2.8GHzのクロック周波数では、コア当たり2*2.8=5.6Gops、あるいはデュアルコアを用いた倍精度浮動小数点では11.2Gopsとなります。
各コアにはキャッシュが独立して存在しますが、他のシステムと異なり共有可能なキャッシュはありません。各コアは2-wayセットアソシアティブのレベル1キャッシュと、全１MBの16-wayデータ・命令レベル2キャッシュを搭載します。レベル1およびレベル2キャッシュは共に、8個の倍精度wordと同等の64バイトのキャッシュラインを用います。レベル2キャッシュはレベル1キャッシュに対してヴィクティムキャッシュとして振る舞います。つまりレベル1キャッシュから追い出されたデータはレベル2キャッシュに置かれます。

動作モード：
システム上でジョブを実行する場合、ユーザーはシングルノード（SN）モードで実行するか、仮想ノード（VN）モードで実行するかを選択できます。 SNモードでは、第2のコアをアイドル状態のままにして、デュアルコアプロセッサの1つのコアだけを利用します。この場合全6 GBメモリが単一コアで利用可能です。 VNモードでは、両方のコアが使用されかつメモリが共有され、各コアで3 GBが使用可能になります。

通信とI/O：
各ノードは、Cray SeaStar2通信チップを用いた高帯域インターコネクトを介して通信します。各デュアルコアプロセッサには、HyperTransportリンクに直接接続された独自のSeaStar2チップを搭載します。 SeaStarチップは、寸法20×12×24の3次元トーラス上に配置されています。各SeaStar2チップは、6つの近傍に高速リンクを提供します。各リンクは、ピーク双方向帯域幅7.6GB / sで伝送が可能です。
計算ノードに加えて、専用のI/Oノード、ログインノード、およびシリアル計算ジョブ用に用意されたノードもあります。HECToRは、上述のトロイダル通信ネットワークに直接接続された12のI/Oノードを有します。これらI / Oノードは、データ記憶システム（すなわち、物理ディスク）にも接続されています。 HECToRのデータストレージは576 TBの高性能RAIDディスクで構成されています。このサービスでは、Lustreの分散並列システムを使用してこれらのディスクにアクセスします。

OS：
計算ノードは、Cray Linux Environment（CLE）と呼ばれる軽量のLinuxカーネルを実行します。 CLEは正式にCompute Node Linux（CNL）と呼ばれているものです。 CLEは、本質的にLinuxの下位バージョンです（Blue Geneの計算ノードカーネル、CNK）。 これは、オペレーティングシステムからの割り込み回数を制限するよう非常に軽量に設計されています。 理論的には、通常のオペレーティングシステムのタスクを専用のハードウェアに委託することにより、計算ノードをオペレーティングシステムで割り込まれないよう保ちます。この利点は、大きなタスク数までアプリケーションの実行時間の変動を最小限に抑え、優れたスケーラビリティを実現することが可能であることです。

コンパイル：
HECToR上では、PGI、PathScaleおよびGNUコンパイラが利用可能です。また、NEMOはデータファイルのI/OにnetCFD$network Common Data Form$ライブラリを利用します。ここでは、Fortran90では最も性能の良いPGI、PathScaleコンパイラ[3, 4]を用いました。

NEMOの性能

NEMOの性能は、異なるプロセッサ数、異なるグリッド構成および異なるコンパイラを用いて解析されました。計測にはコードが出力するtime.stepファイルを用いました。ここで示すのは、NEMOバージョン2.3によるもので、モデル時間ステップを60にして計測しました。
NEMOは、ソースファイルpar_oce.F90内でプロセッサグリッド数と利用するプロセッサ総数を設定します。その変数は、jpni（i方向のプロセッサ数）、jpnj（j方向のプロセッサ数）およびjpnij（プロセッサ総数）です。例えば総数256プロセッサを用いて16×16プロセッサグリッドを実行する場合、jpni = 16, jpnj = 16, jpnij = 256、となります。

· jpni = jpnjケースでのスケール性能

この制限下でプロセッサ数を64 $8x8$から1024 $32x32$まで測定しました。PathScaleコンパイラは96以下の場合に用いました。PGIコンパイラはPathScaleよりも僅かに良好な性能を示しました。

· シングルコアとデュアルコアでの性能比較

一般にシングルノードモードの方がバーチャルノードモードよりも良い性能を示します。これは、シングルノードモードの方がメモリーとI/Oでの競合が少ないからです。実際の測定結果では、シングルノードモードの方が18.95%高速でした。しかしながら、これはヴァーチャルノードモードよりもノード単位コストが高価です。よってシングルノードモードは絶対的な速度が必要となるクリティカルな実務計算に用いるべきです。

· 異なるグリッド分割の性能比較

ここではプロセッサ数を固定して、異なるグリッド分割の影響を調べました。コンパイルにはPGIコンパイラを用いて、128,256,512プロセッサで計測しました。jpni=jpnjが困難なプロセッサ数では、jpni<jpnjとなるように選択されたjpniの値を用いて、できるだけ互いに等しい数字に近くなるべきであることを示唆しています。

· スケール性能

明らかにNEMOは1024プロセッサまでスケールしています。ただしコストと性能のバランスが取れるのは128か256プロセッサの場合です。

· 陸のみのセルの除外

ここでもjpnij = jpni x jpnjの場合を測定します。グリッドの分割のやり方によっては、陸のみのセルが生じます。これは、海洋モデルに不要で削除が可能であり、コード上はjpnij≤jpni x jpnjとできることを意味します。
NEMOは陸のみのセルを自動では削除しないため、ユーザが指定しなければなりません。ここではNOCSのAndrew Coward博士によるツールを用いて海洋と陸地セルの区別を行いました。
こうして必要となるプロセッサ数は一般的には10%、多い時には25%削減できることが判りました。陸セル削除の性能への影響を128から1024プロセッサグリッドを用いて調べた結果、256以上のプロセッサ数では7-10%の実行時間の削減が示されました。

·最適なプロセッサ数

OCSの研究者は、HECToR上で12時間のジョブを用いて、365モデル日数のシミュレーション実行を希望しています。現状で可能なのは、221プロセッサによる300モデル日数までです。12時間で完了させるには、単純な計算で60モデル時間ステップ（１日）の計算時間を118.36秒以下で完了させる必要があります。この際の最適なプロセッサ数を求めることが重要です。

·ファイルI/Oと初期化に掛かる時間

250プロセッサまでは、全体実行時間と60時間ステップ実行時間は同じ傾向にありますが、それ以上のプロセッサ数では大きく異なる振る舞いを示します。ここでは初期化とファイルI/Oに掛かる時間が50%まで増加します。逆に60時間ステップ実行時間は5-10%程度の揺らぎしか見られず比較的安定しています。初期化とファイルI/Oの大きな実行時間の変動は、他のユーザと共有するHECToRのファイルシステムの負荷状況によるものです。

並列コードのためのI/O戦略

並列コードでは通常以下のI/O手法の内どれかを用います：

1. マスタ/スレーブ： 一つのマスタプロセッサがI/Oを行い、スレーブプロセッサとの間のデータ通信を行います。スレーブプロセッサは通常、I/Oが行われている間はアイドル状態です。計算時間がI / O時間よりも遥かに大きい場合に、この手法は適切でしょう。しかしながら、膨大な量のI / Oを含むコードでは、この手法は性能に大きく影響する可能性があります。ただし、実装が容易であるため並列コードで使用されるI / Oでは最も一般的な形式です。これまでは、比較的少数のプロセッサ上で適切なこの手法が多く用いられていきました。しかしながら、近年のプロセッサ数の増加に伴い、この手法は理想的とは言えなくなって来ています。
2. マルチマスタとスレーブグループあるいはI/Oサブグループ： マスタスレーブ手法と似ていますが、この場合は自身のスレーブプロセッサグループを持つ複数のマスタプロセッサが用いられます。この手法は、シングルマスタプロセスが持つI/Oオーバーヘッドを削減し、I/Oに必要なメモリも削減します。ただし、正しい順序でI/Oを実行するには同期処理が必要となります。この同期処理は、複数のマスタープロセッサーを使用することによる利得を相殺することが有り得ます。
3. 並列I/O： 各プロセッサは自身の担当するデータを自身の担当するファイルに書き込みます。その後コマンドや別のプログラムにより、正しいデータ順序へ纏め上げる必要があります。この手法は全てのプロセッサがアイドルしないで動くため、マスタスレーブ手法より効率的です。しかしながら、スケーラビリティ上の制限もあります。多くのOSは、同時にI/O可能なファイル数に制限があります。Unix実装によってはこのファイル数は1000程度で、コードによっては厳しい制限になり得ます。例えば1000ファイル制限において、各プロセッサが10ファイルの書き込みを行う場合、100プロセッサに制限されます。よって、大規模なシミュレーションでは別の手法が必要です。
4. MPI-I/O： MPIの拡張およびMPI-2標準機能です[6]。これは、MPIライブラリを用いた並列I/O関数ライブラリです。一つのファイルが全プロセッサにより書き込まれ、並列I/Oの制限を回避します。各プロセッサはファイル内の地震が担当する領域へデータを直接書き込み、後処理も不要です。並列I/Oの場合と同じく、各プロセッサはアイドルすることはありません。ただし全てのベンダー実装が存在するわけではありません。

各手法の性能予測に利用可能な、多くのI/Oベンチマーク結果が参照可能です。

·NEMOの現状のファイルI/O

NEMOは、殆どの入力データとリスタートファイルを並列I/Oで読み込みます。例えばnamelistファイルなどの幾つかのファイルは、マスタスレーブで読み込まれます。
出力は並列I/Oで行われます。入出力バイナリーデータは通常はnetCFDフォーマットを用いるため、I/O手法の変更に当たっては注意が必要です。NEMOは、現状ではnetCDF version 3.6.2を用いますが、将来は性能がより良いと考えられるversion4.0へ変更される予定です。
netCFDを用いる事で、ファイルにポータビリティが付与されます。NEMOの出力サイズと後処理を考慮するとMPI-I/Oへの変更は現実的でなく、既存の並列I/Oの改善が必要です。

NEMOは入出力共にnetCDFファイルを用います。netCDFは、科学技術データファイルの読み書きのためのインターフェイス、データフォーマットおよびソフトウェアライブラリで、マシンアーキテクチャに独立なポータブルなフォーマットです。ここでは、netCDF 3.6.2および4.0と、zlib version 1.2.3およびHDF5 version1.8.1をインストールしました。ライブラリはPGIおよびPathScaleコンパイラでコンパイルし（性能差はありませんでした）、netCDFのテストコード$nc_test/large_files.c$、および4GBファイルを用いてベンチマークを行いました。

入出力時間はファイルサイズに対してほぼ線形に変化し、PathScaleコンパイラでコンパイルされたnetCDF 3.6.2はPGIコンパイラでコンパイルされたものよりも一貫して高速でした。

netCDF 3.6.2の代わりにnetCDF 4.0を使用したNOCSCOMBINEコードの性能から、NEMOのパフォーマンスが大幅に向上する可能性があります。使用するディスク容量は3分の1に減らすことができ、この情報をディスクに書き込む時間は4分の1に短縮できます。後処理段階におけるデータ圧縮および圧縮解除にかかる時間は、定量化する必要はありますが初期の結果は有望です。

NEMO V3.0

ベンチマーク結果から、NEMO V3.0は以前の2.3と同様なスケール性を示しました。次にNEMO V3.0へnetCDF4.0を導入しましたが、顕著な性能改善は示されませんでした。我々のテストモデルでは、60の時間ステップを実行し、30の時間ステップ毎にデータを出力し、60の時間ステップ後にリスタート出力ファイルを書き出します。しかし実際のNEMO実行では、モデルは通常30000ステップ毎の出力と1800時間ステップ毎にリスタートファイルを出力し、10,000以上の時間ステップを実行します。よって、出力ファイルサイズの縮小により実行時間の改善が期待されます。

NEMOのAGRIFネストモデル

ネストモデルは粗い海洋モデル内で実行されます。これは例えば、2度モデル内に入れ子になった1度領域です。
NEMOのネストモデルは、Adaptive Grid Refinement in Fortran $AGRIF$プリプロセッサを呼出すことで、ネスト領域のコードを生成します。デフォルトでNEMOは、次元$jpi, jpj$の配列を用います。ここで$jpi, jpj$はコード内で設定されるパラメータです。このプリプロセッサは、インタフェースルーチンを挿入することによってコードを完全に再構築します。このインターフェイスルーチンは、動的に割り当てられた特殊なAGRIFデータ型から配列情報を渡しますが、そのサイズは所望のネスト領域のサイズに基づいて決定されます。AGRIFプリプロセッサは、異なる時空間解像度を持つグリッド上で同一海洋モデルの実行を可能にします。NEMOのネストモデルの詳細は文献[10]を参照してください。

NOCSチームからは、BASICおよびMARGEDと呼ぶ2つのネストモデルの提供を受けました。BASICはNEMOの既存コードとほぼ同一で、AGRIFプリプロセッサの使用が仮定されています。このモデルは、2度モデルの内側で1度モデルが実行される、ネスト領域を一つのみ含んだモデルです。MARGEモデルは、NOCSが変更を加えたBASICモデルの拡張版です。これは2つのネスト領域を持ちます。外側の1度領域内のネスト領域に1/4度領域を設定した、より高解像度の実行を行うものです。

謝辞

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

文献

[1]	NEMO Home page http://www.nemo-ocean.eu/
[2]	User Guide to the HECToR Service $Version 1.0$, http://www.hector.ac.uk/support/documentation/userguide/hectoruser/hectoruser.html
[3]	Network Common Data Format $netCDF$ web page, http://www.unidata.ucar.edu/software/netcdf/
[4]	NetCDF User's Guide for Fortran 90, http://www.unidata.ucar.edu/software/netcdf/f90/documentation/f90-html-docs/
[5]	CDFTOOLS web page, http://meolipc.hmg.inpg.fr/CDFTOOLS/cdftools-2.1.html
[6]	Message Passing Interface Forum, 2008. MPI: A Message-Passing Interface Standard, Version 2.1, High Performance Computing Center Stuttgart $HLRS$. http://www.mpi-forum.org/docs/mpi21-report.pdf
[7]	Zlib web page http://www.zlib.net/
[8]	HDF5 web page http://hdf.ncsa.uiuc.edu/HDF5/
[9]	HDF5 1.8.1 Release Notes ftp://ftp.hdfgroup.org/HDF5/prev-releases/ReleaseFiles/release5-181
[10]	NEMO Web page - AGRIF nesting tool $accessible only to registered users$ http://www.nemo-ocean.eu/index.php/Using-NEMO/Pre-and-post-processing-packages/Pre-Processing/AGRIF-nesting-tool
[11]	EPCC news article - NEMO: improving ocean modelling, http://www.epcc.ed.ac.uk/downloads/epcc news/EPCCNews62.pdf
[12]	Scientific computing world article - Weathering Well, http://www.hpcprojects.com/features/feature.php?feature id=228