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

概要

3次元エアロゾル化学輸送モデルMPI-TOMCAT-GLOMAPmodeを、CPUコストの多くを占めるコード部分に対して、doループ周りのOpenMP指示行を更新し、再設計することにより性能を改善しました。OpenMPとMPIを用いる事で、コードをマルチコアHECToR上でより効率的に並列化しました。ここでは、各MPIタスクは複数のスレッドを伴ったSMPプログラムのように振る舞います。この新しいハイブリッドOpenMP/MPIバージョンは実行時間を短縮し、より長期かつ解像度の高いシミュレーションを可能にします。新しいハイブリッドバージョンはまた、MPIタスクに対してノード上の全メモリーへ競合なしにアクセスを可能にします。
この改善により、以前はMPI通信ボトルネックのため64コアまでしか不可能だったのに対し、テストケースで128コアまで良好なスケーラビリティーを与ました。Cray XT4では、2OpenMPスレッドの場合1.4倍に高速化されており、これはコードの45%がシリアル実行の場合の理論値に近い値となります。4スレッドの場合は2倍になり、これもほぼ理論値です。
XT6でのテストケースでは、OpenMPによる高速化は32MPIタスクの場合と、64プロセッサへ分解された場合とでは性能が異なりました。前者では2スレッドが最適であったのに対し、後者では3スレッドでした。

目次

• 1.　イントロダクション
• 1.1 アプリケーション・ソフトウェア
• 1.2 並列プログラミングのためのハイブリッドモデル
• • 1.2.1 OpenMPスケジューリング

• 2.　MPI-TOMCAT-GLOMAPmodeの説明
• 2.1 コードライブラリの概要
• 2.2 トレーサ移流ルーチン
• 2.3化学プロセスとエアロゾルプロセス
• • 2.3.1 CHIMIE
  • 2.3.2 GLOMAP-mode
  • 2.3.3 ASAD

• 3.　OpenMPの予想される全効果

• 4.　結果
• 4.1 本セクションの概要
• • 4.1.1 ケース説明
  • 4.1.2 MPI-only
• 4.2 Cray XT4での結果
• 4.3 Cray XT6での結果
• • 4.3.1 Magny-Coursプロセッサ上でのハイブリッドモードの準備
  • 4.3.2 MPI-onlyモードの結果
  • 4.3.3 Cray XT6での64MPIタスクのハイブリッドモードの性能
  • 4.3.4 Cray XT6での32MPIタスクのハイブリッドモードの性能
  • 4.4 考察

• 5.　まとめ

1.　イントロダクション

本プロジェクトの目的は、マルチコア・スーパーコンピュータ・アーキテクチャをより有効に活用するために、コード内の既存のOpenMP指示行を更新して改善することで、3次元エアロゾル・化学輸送モデルMPI-TOMCAT-GLOMAPmodeの性能を改善することです。本作業は、EPSRC HECToR distributed CSE programme (dCSE)として行われます。技術的な作業はnAG Ltdスタッフが行い、作業監督はUniversity of Leeds School of Earth and EnvironmentのNational Centre for Atmospheric Science (NCAS)の研究者です。本作業の受益者には、リーズ大学と他の英国の大学でTOMCAT-GLOMAPmodeを利用する学術研究者の大きなグループだけでなく、海外のフィンランド・ヘルシンキ大学やオーストラリア(CSIRO)のユーザも含まれます。

本プロジェクトは、HECToRがCray XT4h(ノード当たり4コア)からCray XT6(ノード当たり24コア、Geminiインターコネクトは未実装)に更新される間に開始されました。テストケースはセクション4で記述されるT42を用いました。

1.1　アプリケーション・ソフトウェア

TOMCAT-GLOMAPmodeは、全球スケールのエアロゾル粒子の輸送と変態をシミュレートし、産業期間に渡ってエアロゾル粒子の性質の変化が地球の気候に如何に影響を与えるかを理解するのに用いられます。このモデルの3つの主要なコンポーネントは以下の通りです：

1. i)：トレーサの移流、対流および境界層(BL)混合(例えば、Chipperfield,2006を参照してください)のルーチンから成る輸送モジュール。
2. ii)：ASAD chemical integrationソフトウェア(Carver et al. 1997)を利用した大気化学モジュール。
3. iii)：エアロゾル微量物理モジュールGLOMAP-mode(Mann et al., 2010)。

このモデルは、既に前回のプロジェクトで性能改善がなされたものです。3次元全球エアロゾル化学輸送モデルは、地表地形を追随するシグマ座標の鉛直レベルの地平での固定の経度/緯度のグリッド上で演算が行われ、成層圏の3次元領域の上部において純粋に圧力レベル上の状態へシフトします。このモデルは"オフライン"で用いられるもので、3次元の風速、温度、湿度場は、ECMWFによる6時間毎の気象再解析場に従って事前に記述されています。

TOMCAT-GLOMAPmodeは既に、水平領域が経度緯度空間の等サイズのプロセッサ要素へ分割されたMPI並列手法が実装されています。ソースコードはnupdateソフトウェアでビルドされ、TOMCATの3つのメインコードのライブラリと、ASADおよびモデルのBL混合部とリンクされます。本調査で用いるTOMCATメインライブラリのバージョンは、UNICATMPP0.91です。このライブラリは、既に複数のOpenMP指示行が含まれており、以前の英国スーパーコンピューティングリソース(CSAR、HPCx)で用いられていたものですが、現在は利用されず、ユーザはTOMCAT-GLOMAPmodeのMPIバージョンを用いています。

前回のプロジェクトでのMPI-TOMCAT-GLOMAPmodeの最適化とプロファイリングからの重要な知見は、XT4の計算ノード当たり一つのMPIタスクを用いた場合が最良の性能を示している事です(CPU利用課金は4倍です)。この後続の本プロジェクトでは、HECToRハードウェアは今後、以下の特性を顕著にしていくことに着目します：

1. i)：プロセッサの高速化よりもチップ当たりのコア数の増加が優先される(すなわち、コア単体の性能よりもキャパシティを増やす)。
2. ii)：コア当たりのメモリー量の減少。

MPIバージョンコード内の既存のOpenMP指示を利用して、ノードのメモリーの有効活用をすべきであり、また既存の64PEでの通信ボトルネックに対してOpenMPスレッドでメモリーを共有して、より多くのコアを使って並列化を実現すべきです。

1.2　並列プログラミングのためのハイブリッドモデル

本報告では、ハイブリッドモデルとは、各ノードが(ハードウェアに対して適切に選択・最適化した)一つ以上のMPIタスクを実行し、そのタスクはノード上のアイドルしたコアへ計算スレッド(OpenMPスレッド)を起動することを言います。これは"mixed-mode"とも呼ばれます。一般にクラスタコンピュータに置いては、ノードはインストール毎にコンフィグされて、ユーザによる変更はできません。ジョブスケジューリング・ソフトウェアは、設定されたノードに対して様々な利用形式を提供します(通常は一様な設定はしません)。ハードウェア設定は、1ソケット・デュアルコア(HECToRフェーズ1a)、1ソケットクアッドコア(HECToRフェーズ2a)、Cray XT6(HECToRフェーズ2b)では2ソケット12コアのノードと様々です。

ハイブリッドコードに必要な作業は、MPIタスクとスレッド間の競合を回避するために、コードの構造を解析することです。コードは、OpenMP指示行を無視するようにコンパイラフラグを設定すれば、通常のMPIコードとして利用可能です。この機能をシングルスレッド実行の性能比較に用います。以下では、用語GMM(GloMAP Mode MPI)およびGMH(GloMAP Mode Hybrid)を用いて並列手法の区別をします。

1.2.1　OpenMPのスケジューリング

DoループへのOpenMP指示は"PARALLEL DO"指示行です。このキーワードに、指示節(clause)と呼ばれるキーワードが続きます。本プロジェクトで用いる指示節は、"shared","private","default","schedule"です。プログラム変数は、privateかsharedかのどちらかの宣言が必要です。OpenMP並列領域では、デフォルトの変数宣言も可能ですが、本プロジェクトでは"default none"を用いて明確な宣言を使用します。キーワード"schedule"は修飾子を持ち、static,(static,block size),dynamic,(dynamic,block size)が指定可能です。
PGIのデフォルトのblock sizeは以下の通りです。

Block size=(number_of_iterations + omp_num_threads() - 1)/omp_num_threads()

本レポートの時点では、"dynamic,1"の性能が良く、この時スレッドは、繰り返しが終わるまで、動作可能になった時点で動的に割り当てられて動作します。

2.　MPI-TOMCAT-GLOMAPmodeの説明

2.1　コードライブラリの概要

本プロジェクトで用いるTOMCATおよびASADのnupdateコードライブラリは、前回のプロジェクトで作成された、UNICATMPP0.91X2とUNIASAD0.2X2です。UNICAT0.81はTOMCATの最新バージョンで、共有メモリー演算モードを持ちます(MPI並列実装前のコード)。このライブラリは、HECToRシステム上でOpenMPのみの性能調査のために小規模ケースで用いられました。この作業は、ノード当たり4コアのHECToRのXT4hで行ったため、OpenMPスレッドが4つまでの制約された作業でした。しかしながら、これは既存のOpenMP指示行や、PBSのリソース割り当て、HECToR上のジョブスケジューリングシステムの理解に役立ちました。

2.2　トレーサ移流ルーチン

単一MPIタスクを用いた簡単な解析から、UNICAT0.81の4つのルーチン(ADVX2,ADVY2,ADVZ2,CONSOM)が、OpenMPが施されて負荷が高いことが判りました。これらのルーチンはモデル内のトレーサ移流を扱います。CrayPAT解析から(表2)、全モデル実行時間の割合におけるトップ5ルーチンが示されました。このセクションでは、MPIタスク当たり4OpenMPスレッドを例に取り、これら4つのルーチンの解析を行っていきます。

ADVX2では、主な外側ループがL=1,NIVで、T42モデルではNIVは31レベルです。4スレッドでループを分割すると3つがスレッド当り8カウントの繰返し数で、残り一つが7カウントです。(dynamic,1)scheduleを適用した場合、どのスレッドがどのループサイクルを担当するかは決められません。

ADVY2でも、主な外側ループがL=1,NIVです。これはADVX2と同じでスレッドは8カウントを実行します。TOMCATには、極を跨る南北フラックスが特別な扱いをされるという特徴があります。これは、grid-boxの極側の面が、経度線に沿って極へ近づいていくと、ゼロに近づいていくためです。そこで、サブルーチンの0.91バージョンでは0.81バージョンと異なり、極領域を担当するMPI呼出しを必要としています。MPI-onlyバージョンで実装された(本プロジェクトとは別)手法は、基礎的なグローバル総和を用います。これはLの繰返し内で生じ、OpenMP実装を阻害しています。このコードは、グローバル総和計算をループ外に移動して書き直され、このために4つの配列塁算器が追加されました。

ADVZ2では、主な外側ループがK=1,MYLATであり、MPI計算領域分割に依存しています。32MPIタスクの場合、一つのパッチ(計算領域)当り、8緯度間隔および32経度間隔となります(表1)。64MPIタスクの場合は、4緯度間隔になります。この解像度と時間ステップの場合は、MPIタスク数は経度線分変化し、プロセス数を増やすとパッチ当たりの緯度間隔数が減少します。

CONSOMの外側ループはK=1,MYLATです。UNICAT0.81バージョンにおいてOpenMPは、Kループ内のループJV=1,NTRA(この場合は36)に対して適用されています。これは初期のバージョンでは、対流係数を緯度毎に外部ファイルから読み込むためです。このOpenMP実装位置はそのままにしました。4OpenMPスレッドを用いる場合は、MPIタスク数に関係なく、スレッド当り9繰返し数分を計算します。

2.3　化学プロセスとエアロゾルプロセス

2.3.1　CHIMIE

CHIMIEルーチンは、大気化学レート方程式(ASAD)を結合するコードを呼出すメインルーチンで、エアロゾル微量物理プロセス(GLOMAP-mode)を計算するコード内に在ります。エアロゾルと化学プロセスのこの2つのモデルは、grid-box毎、および緯度毎のデータに対して処理されます。緯度ループ内では、3次元モデルのグリッド上の配列は、経度・標高平面へコピーされてASADとGLOMAP-modeで利用されます。こうしたデータは長さNBOXの1次元配列へ格納され、ASADとGLOMAP-modeの入力データとなります。OpenMP並列は緯度平面のループ"loop 6"に適用されます。各OpenMPスレッドは、ループカウント毎に1平面を処理します。例えば4スレッドの場合、最初の4つの緯度は異なるOpenMPスレッドで処理されます。スケジューリングは(dynamic, 1)なので、各スレッドは、他の平面の処理を邪魔しないように必要な分平面を処理します。スレッドは、作業を終えた場合は、ループカウンタを見て次にどの繰返しを処理するかを決定します。こうして緯度間の作業量をバランスしていきます。

2.3.2　GLOMAP-mode

GLOMAP-modeコード(Mann et al., 2010)は通常UKCA_で始まるサブルーチン群で構成され、これらは全て、grid-boxデータの新たにコピーされた1次元配列(NBOX個)で処理します。CHIMIEの緯度ループは平面データを展開し、それをGLOMAP-modeのメインルーチンUKCA_AERO_STEPへ渡します。データは全てprivate宣言され、各スレッドは独立に1平面を処理します。副作用としてスタックメモリーが増加します。もしその限界が小さい場合はコードはフォールトします。よって環境変数OMP_STACKSIZEを1GBに設定しました。

2.3.3　ASAD

ASADコード(Carver et al., 1997)は他の研究グループ(ケンブリッジ大学)が開発したもので、TOMCATルーチン(UNIASAD0.2X2)へ別のコードライブラリから供給されていました。ライブラリ内の既存のOpenMP指示行は、MPIが追加されたバージョンの前のバージョンから変更されていません。よって、UNICAT0.81のOpenMP版TOMCATと共にUNIASAD0.2を用いることが可能です。この化学サブシステム全体は、CHIMIEの緯度ループ(loop 6)下で処理され、個々のgrid-box上で計算されます。ここで、あるCOMMONブロック内のデータがTREADPRIVATEを用いてスレッド毎に保持されている、ということを確認する作業が必要でした。

3. OpenMPの予想される全効果

表2は、トレース測定における代表的な時間データを示しています。UKCAの時間はCHIMIEの時間に含まれます。大きなMPIタスク数におけるMPIおよびMPI_SYNCの増加は、コードのMPIセクションに改善余地がある事を示しています。

表2のGMM onlyの列は、5ルーチンに起因する、シミュレーションの実行時間の割合を示します(MPIを除く)。CHIMIEは一貫してシミュレーションの50%を占めています。ADVY2は、極のパッチによる余分な仕事のために高負荷になっています。

オリジナルのシリアル処理の割合をスレッド数で分解した、理論的な高速化率を表3に示します。これはアムダール側と同じです。以下の式のAは通信時間を除いた場合の理想的な実行時間を示します。

      A = S + P/N

シミュレーションの経過時間は、シリアル部分の時間Sと、並列部分の時間Pをスレッド数Nでスケールしたものの和です。実際にはより複雑で、あるサブルーチンはスレッド数がループカウントを超えたらスケールしなくなります。これは表3の"Total for GMM"が示しており、ここでは、OpenMPスレッド数が最小のループカウント(M32では8)を超えてしまいます。この理論計算は通信オーバーヘッドを考慮していませんが、表3では"Total for simulation"行にその結果を示します。

表3の見方を説明するために、8スレッドの列を考えます：オリジナル・シミュレーション(MPIのみの計算)に対するGMMの割合は16%です(74%から減少しました)。MPIタスクのシリアル実行部分は変化しないことが仮定されています。また、MPIセクションで通信パターンが変化しないことも仮定されています。この割合を並列セクションに加算します。こうすると42%となり、高速化率で表現すれば2.38という値になります。これは楽観的な値です。シリアル実行の5つのサブプログラムが存在していますが直接計測していません。よってこのスケール性能は理論値です。

コード内のこの5箇所は、OMP PARALLEL DO指示行を持ちます。しかしながら、これらは全て同じループ長ではありません。これは短いループ長を持つため高速化に上限がある事を意味します。即ち、もしループ長が8の場合は、それ以上にスレッドを追加しても共有すべき仕事が存在しません。溢れたスレッドはWAIT状態になります。もしループ長がスレッド数で割り切れない場合は、スレッドの仕事量に分散が生じます。32MPIタスクの例を表4に示します。

表4の括弧内の数字は、ループ長がスレッド数で割り切れなかった場合の余りです。

4.　結果

4.1　本セクションの概要

本セクションは、32,64,128MPIタスク領域分割での結果と共に、MPIのみの場合のベースライン計算について記述します。その後に、32,64MPIタスクの場合のハイブリッド並列結果を示します。Cray XT4hとXT6での結果も記します。

ハイブリッド並列とMPIのみの場合を並べて表示します。その構成を示す標識を決めます。小文字のnで全MPIタスク数を表し、計算領域の物理的な分割を表現します。大文字Nで物理ノード当たりのMPIタスク数を表します。小文字dでMPIタスク当たりのOpenMPスレッド数を示します(depthと言います)。XT6でのパラメータとして、大文字Sを物理ノード上のヘキサコア当たりのMPIタスク数とします。

例えば、コードn64N4S1d4は、全64MPIタスク、ノード当たり4MPIタスク、ヘキサコア当たり1MPIタスク、MPIタスク当たり4スレッドを用いる事を意味します。スレッド数にtを用いることも有ります。小文字dは、aprunのフラグでもあり、MPIタスクが指定されたコア数を共有することを意味します。よって、d4はMPIタスクが4コア毎に存在することを意味します。

4.1.1　ケース説明

このシミュレーションの時間ステップは1800秒で、T42解像度グリッドを用います。本作業では、実行形式は2つあります。一つはMPI-onlyで、ソースは同じですがOpenMP指示行を無視するコンパイルフラグを用いたものです。もう一つは、ハイブリッドバージョンです。幾何学的な領域分割を用い、T42グリッド(128x64x31 grid-boxes)は矩形のMPIトポロジーへ分割されます(4x16)。パッチ：32x4x31 grid-boxesは32MPIタスクのパッチの半分のサイズです。

4.1.2　MPI-only

このモードは前回のプロジェクトで広範囲に調査されています。ここでは、XT4とXT6の比較を示します。図1はXT4とXT6上のMPI-onlyのタスク配置の影響を示しています。XT4での2つの配置の違いは、N1d1がノード上の全メモリー(8GB)を持ち、3つのコアがアイドルしていることです。これをXT6のヘキサコア当たり4MPIの場合と比較します。その差は、XT6でのMPIのノード内通信性能の良さにあり、飽和ノードは非飽和の場合と同程度高速であるためです。その他にも、ハードウェア、メモリーキャッシュ、クロックスピード、コンパイラ最適化れべるからの影響が有ります。

図1: XT4とXT6でのMPI-onlyのタスク配置の比較

XT6上での配置の差は、XT4での場合に比べてそれほど大きいものでありません。XT4上でのノード当たりいタスクの場合は、8GBメモリーにアクセスできますが、XT6上でノード当たり16タスクまで制限させた場合(ヘキサコア当たり4タスク)は、タスク当たり2GBのみになります。

4.2　Cray XT4での結果

全セクションの結果は、ノード当たりのタスク数を減らせば計算速度が上がることを示しています。更にOpenMPを適用した場合の性能改善を表5と図2に示します。表5において、4OMPスレッドを用いた場合はMPIタスク数の4倍と比較されます。32MPIタスクの場合、4スレッドを用いた計算(全128コア)は、ノード当たり4MPIタスクの場合に約3倍高速化しています。128タスクの場合は2倍にしか高速化されません。同様に16MPIタスクの場合も4スレッド化により高速化されています。128MPIタスクの場合も同様です。これらは、MPIジョブをノード当たり1タスクで拡散する場合に、OpenMPスレッド化によりステップ時間がさらに短縮されたことに起因する結果です。

図2ではMPIの配置による4つのグループ分けをしています。各グループの最初のバーは通常運用のノード当たり4MPIタスクです。残りの3つはノード当たり1MPIタスクで、それぞれ1，2，4スレッドを用いたもので、OpenMP実装の効果を示します。

32MPIタスクの配置が現状最良のモードです。128MPIタスクにすると、4倍のリソースを使って2倍しか高速化しません。つまり2倍高価です。しかしながらハイブリッドモードにすると、同じ課金で(32ノードで)約3倍に高速化しますし、3割高のみになります。2スレッドの場合は、表2の理論性能に近い値、即ち2スレッドは1.4倍、4スレッドは2倍、になります。15か月のシミュレーションでは12時間の計算を行いますが、OpenMPを用いれば更に長い(36か月)シミュレーションを実行することが可能になります。

図2: XT4hでのハイブリッドバージョンの性能

この他の知見として、小さなMPIタスク数を用いた際のOpenMPによる加速は、MPIタスク数が大きな場合に比べて利得が大きくありません。測定ではノードのコアを飽和させていますが、ハイブリッドで使用しています。図3は、並列配置によりグループ化したものです。最初のグループはMPI-only、2番目は1スレッドのハイブリッド、3番目は2スレッド、4番目は4スレッドを用いたものです。OpenMP指示行はループの最適化に影響するため、ハイブリッドコードは多少遅くなります。これは最初と2番目のグループの差としてみることが出来ます。

図3: ノード上の全てのコアを用いた場合のステップ時間の比較

各グループのバーはそれぞれ、32,64,128MPIタスクによる異なる配置を表し、MPI並列のスケール性能を示します。最も性能が良いのは128コアのケースです。ノード当たりのMPIタスク数を減らすと、時間ステップのに掛かる時間は減少します。OpenMPスレッドを適用すれば更に加速されます。64コアを用いた場合の配置間の差は、MPIタスク数の減少に伴う時間ステップの減少が有りますが、比較的少ないです。課金はノード時間で課されるので、単一シェードバー間の比較が直接シミュレーションコストに反映されます。

4.3　Cray XT6での結果

4.3.1　Magny-Coursプロセッサ上でのハイブリッドモードの準備

ノードの複雑さ(2つのMagny-Coursプロセッサから構成される)から、メモリーへのアンバランスなパスが存在し、ユーザは、リソースを最大限に活用するために(システムのデフォルトよりも)意識的したジョブ配置を要求されます。XT6でのGLOMAP測定には、以下のような様々なパラメータが可能です：

1. i)：MPIタスク数：n=32,n=64
2. ii)：ノード当たりのMPIタスク数：N=1,2,4,8,12,24
3. iii)：ヘキサコア・ダイ当りのタスク数：S=1,2,3,4,5,6
4. iv)：MPIタスク当たりのOpenMPスレッド数：d=1,2,3,4,6,12,24

以前のコード解析のセクションに記したように、OpenMP並列ループカウントはプログラムを通して様々で、大きなスレッド数を用いても大きな利得を得られるわけではありません。MPI-onlyバージョンの時間測定には飽和ノードを用いてます。

OepnMPを起動するには-mpフラグでビルドします。これは、コードブロックを扱う最適化のやり方を変更します。例えば、CONSOMにはOpenMPが最外側ループの内側に存在するセクションが有ります。ここで、OpenMP指示行がアクティブである場合は、コンパイル中の外側ループの最適化は阻害されます。MPI-onlyバージョンの実行結果を、OMP_NUM_THREADS=1とした場合のハイブリッドバージョンと比較したのが図4、図6です。一般的に、シングルスレッドのハイブリッドモード実行は多少遅くなります。

本プロジェクトで用いたテストケース(T42グリッド)は、128経度間隔と64緯度間隔といった、2のべき乗の計算領域を持ちます。これは、以前の1ノード当たり1コアのHPCマシンでは、ノード数を2のべき乗にアレンジするのに都合が良いものでした。しかしながら、既に記述したXT6はノード当たり24コアのメニーコアシステムであり、このような制限はありません。これまでは、環境変数とqstatコマンドを使用して、PBSリソース要求にaprunコマンドのオプションを関連付けていました。ハイブリッドモードではこれは正しくなく、aprunの-dオプションでOpenMPスレッドへコアを割り付けます。十分なコアが割り当てられていることを確認するために、ノードあたりの実際のコアの倍数になるように、PBSのmppwidthオプションを用いることが良いでしょう。例えば、mppwidthは、32MPIタスク、6OpenMPスレッドの場合(8ノード)、192と指定します。次にaprunコマンドを、MPIタスクが割り当てたノード内に含まれるように正しく設定します。例えば32タスクの場合は以下のようにします：

aprun -n 32 -N 4 -S 1 -d 6 ./glomap.exe

ジョブ投入スクリプトには、OMP_NUM_THREADSの設定が必要で、環境変数を、aprunコマンドの-dオプションの値として以下のように用いることが可能です。

aprun -n ${NTASK} -N ${NTASKPN} -S 1 -d ${OMP_NUM_THREADS} ./glomap.exe

ここで、NTASKやNTASKPNはPBSとは独立に設定します。

4.3.2　Cray XT6でのMPI-onlyモードの結果

MPI-onlyモードでは、32タスクと64タスクには最適配置が存在します。これはステップ時間に掛かる課金をベースにしたもので、アイドルするコアを残した状態で(それでも課金されます)、実行時間はキャッシュとメモリーパスにより影響されるためです。ヘキサコア・ダイはノードメモリーが32GBであり、コア当たり利用可能なメモリーがXT4hの2GBから1.3GBへ減少しています。

32MPIタスクの場合は2ノードを使って16コアが残り、64MPIタスクの場合は、3ノードを用いますが8コアはアイドルします。結果として、時間ステップ当りのコストは、ノード課金という制度から非線形に振る舞います。

MPIタスク総数は24の倍数が好ましく、そうでなければ最後のノードにアイドルするコアが存在することになります。例えば32MPIタスクの場合、最初のノードに24コアを用いて二番目のノードに8コアを用います。ノード当たり8コアを残すように均等にタスクを分散すれば、この16コアの余分なコストは軽減することが可能です。これはステップ時間と全実行時間の減少によるものです。図4では、最初の3つのバーが2ノードから32ノード(ノード当たり1タスク)までの実行時間の比較を示しています。他の６つのバーはハイブリッドモードのセクションで議論ます。

図4: 32MPIタスクケースの実行時間(ハイブリッドモードを含む)

64MPIタスクの場合、最小ノード数は3で、72コアが予約されて8コアがアイドルします。図5では、時間ステップ当りのAU(課金単位)と実行時間の2種類のバーを示しています。これらはステップ時間(第2系列)順に並べられています。最左翼のバーは最高密度のMPIタスク配置です：最初の2ノードは飽和ノードで、残りの一つは8コアがアイドルしています。

図5: 様々なノード配置を用いた64MPIタスクの実行結果

64タスクを均等に割り振ろうとすると、更にノードが必要となり、アイドル・コアが増えます(更に24コアを足して、合計32コアが余ります)。これは新たな配置で相当する性能改善がない限り、コストの増加を招きます。結果を見ると、この均一分散配置(n64N16S4)よりも元の最小ノード配置の方が経済的です。
均一分散配置では実行時間は1割減少しますが、追加の第4のノードにより3割課金率が上昇します。

図5の第2,3,4番目のバーは、ノード当たり4MPIタスクのみを用いて(n64N4)、ヘキサコア当たり4MPIタスク、2MPIタスク、1MPIタスクの配置ケースを示します。この配置は16ノードで、ノード内通信と分当たりのコスト(課金率)は同じ量です。しかしながら、ノード間では異なるデータ通信パスを持ちます。全MPIタスクが(単一プロセッサ上の)同じソケットを持ち、ヘキサコア・ダイ当り2タスクに分散できれば、ステップ時間は最も小さくなります。全MPIタスクが同じヘキサコア・ダイ上に配置されると最も遅くなります。これはノード間のMPI転送に競合がある事を示します。これは、ローカルメモリー制限と全タスクによるキャッシュ共有が原因である可能性が高いです。ヘキサコア・ダイ当り1MPIタスクの場合は、ソケット間のノード内通信によるオーバーヘッドが生じます。これはヘキサコア・ダイ間のMPI通信によるものです。

「利用可能コア」に対する「使用済コア」の割合は、各エントリのラベル表示に記されています。ステップ時間の秒数はステップコストと同程度の大きさです。

4.3.3　Cray XT6での64MPIタスクのハイブリッドモードの性能

64MPIタスクのケースでは、MPIタスクを高密度にパッキングするのには最小で3ノード必要で、そこでは8コアが未使用になります。ノード当たり4MPIタスクへ分散すると、ヘキサコア当たり1MPIタスク/OMP_NUM_THREADS=6になります。この配置では、MPIタスク当たり8GBのローカルメモリーが有ります。しかしながらこれは40%しか速くならず(図6)、N4S1D6は384コアを使いますが、実行時間は60%より少し大きい程度です。

この配置では、MPIタスク当たりgrid-boxは4しかなく、CHIMIEサブルーチンの主要な作業ループ(K=1,NLAT)は4スレッドしか用いていないため、2つの余分なスレッドは、メモリー上にあるにもかかわらず計算に寄与していません。

図6: Cray XT6での64MPIタスクのハイブリッド配置

最右翼の2つのグループはハイブリッド実行ではありません。他の条件のバーはこの時間でスケールされています。図から、全てのテストケースは時間が減少していますが、コストは様々です。N2の4つのグループはOpenMP並列の効果を示しますが、8スレッドが6スレッドよりも遅くなるという不思議な結果を示しています。これは、スレッドに均等に分散された仕事が不十分なことと、余分なスレッドがメモリーを競合することの寄与によるものです。

4.3.4　Cray XT6での32MPIタスクのハイブリッドモードの性能

図7は、様々なOpenMPスレッド数でのハイブリッドモードの性能を示しています。OpenMPスレッド数の増加は、ノード当たり1MPIタスクの最大24スレッドまで一貫してステップ時間を改善します。MPIタスクを分散させたときのコスト増大は、OpenMPスレッドによる時間減少よりも大きな比率を持ちます。これは主に、問題サイズがスレッド数に適合しているためと考えられます。

XT6でのMPI-onlyのステップ時間1.65秒は、XT4hでの同じ配置における2.17秒よりも既に1.3倍高速化しています。実行時に予約されたノード数に対する適切な配置を用いれば、更に高速化が可能です。これはMPIタスク当り1スレッドでハイブリッドモード実行を行えば確認できます。右から2番目のグループn32N16S4D1がそれで、1.48秒となりました。

図7: 32MPIタスク配置でのハイブリッド並列GLOMAPの性能

2OpenMPスレッドは更に速く、1.69倍高速で、コストはMPI-only実行の90%です。3OpenMPスレッドでは2.1倍高速化し、7%のコスト減少です。1スレッド配置との比較では、1.27倍の高速化と4%のコスト削減です。このコスト的に良好な配置を、XT6システムでの32MPIタスクの場合の標準配置とすべきでしょう。

4.4　考察

このソフトウェアにおいては5つのdoループのみをOpenMPで加速しました。ループ長は実装の効率に影響します。ループ長がスレッド数の整数倍でない場合は、アイドルするスレッドが存在しつつ、その他のスレッドが計算を行う場合があります。指示節dynamicは、ループ繰返し毎の作業が均等でない場合に限り、この負荷分散を軽減する手法の一つとなります。

全プログラムの中でOpenMP指示行を適用した緯度のループが存在する箇所は2つあり、これはCHIMIEとADVZ2にあるループです。これらは、パッチ当たりの緯度点以上にスレッドを与える場合は利点はありません。(CHIMIE内の)GLOMAPの寄与は実行時間の約55%を占めるため、加速すべき最良の対象はパッチ当たりの緯度点数です。

その他のOpenMPが適用された3つのコードセクションは、XT6のノード当たりのコア数に等しい32の繰返し数を持ちます。このセクションは、シリアル実行時間では小さな比率しか占めませんので、CHIMIEで達成したほどの実行時間上の大きな効果はないでしょう。

スレッド数をパッチ当たりの緯度点数に一致させれば、OpenMPによる加速が効きます。T42の場合は、その分割が、パッチ当たり2スレッドの最大128MPIタスク(通常の利用時は32MPIタスク)に制限されていますが、GLOMAP-modeのハイブリッドバージョンにより、以前よりも経済的に有利に多くのコアを用いる事、即ち32MPIタスクで128コアを用いたシミュレーションが可能になりました。

XT6システムはXT4hよりも、ノード当たりのタスク数を多く用いることが可能です。スパースなMPIタスク配置を行えば、更に効率的な計算が可能です。今回のXT6での作業は概略的なものですが、2種のMPIタスク分割において最適なモードを決定することが可能になりました(ノード当たり3スレッド/8タスク、および2スレッド/12タスク)。

5　まとめ

本プロジェクトにおいて、TOMCAT-GLOMAPの既存のOpenMP指示を更新し、MPIバージョンの利用を再設計しました。この新しいハイブリッド並列バージョンは、HECToRのCray XT4システムとCray XT6のフェーズ2状に実装され、テストされました。

実装は成功裏に完了し、ノード上のアイドルしたコアへOpenMPスレッドがロードされ、シミュレーションおステップ時間を削減して、実質的な性能改善が示されました。MPIタスクのスパースな配置により、解像度と複雑さを向上させたシミュレーションが可能になりました。OpenMPスレッドの追加はメモリーがより必要になりますが、MPIタスクを追加するケースのようなコード全体の複製によるメモリー増加ほど多くはありません。

測定の解析から、最大2.5倍の高速化が示され、特にXT4マシンでもこれに近い値が実証されました。これまでは64MPIタスクを用いる事は稀でしたが、この手法は32及び64MPIタスク配置で有効であることが示されました。XT6では、ノード上のタスクとスレッドの配置のやり方はより複雑です。

謝辞

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

文献