＊ここに掲載するのは、STFC utherford Appleton Laboratory のDominik Jochym博士らによるHECToRレポート「Boosting the scaling performance of CASTEP: enabling next generation HPC for next generation science, Dominik Jochym1, Jolyon Aarons2, Keith Refson1, Phil Hasnip2 and Matt Probert2, 1Science and Technology Facilities Council, Rutherford Appleton Laboratory, 2Department of Physics, University of York, April 02, 2012」を要約したものです。
MPIバッファメモリーの最適化
例えば、チェックポイント操作中の多くのプロセスからマスタプロセスまでの多数の1対1MPI通信は、MPIの「予期しないバッファ領域外」エラーを引き起こす可能性があります。もしMPI受信呼出しが事前にポストされていない場合は、受信呼出しに達するまで、” unexpected "メッセージをメモリに格納します。このエラーを回避する方法の1つはバッファのサイズを増やすことですが、これは望ましくありません。なぜなら、このメモリは、ジョブの本来の目的に利用可能なメモリを犠牲にして、ジョブ全体に渡って予約しなければならないからです。このセクションでは、電子構造計算コードCASTEP [1]の文脈で、MPI集団通信を使用したこの問題に対する解決策を議論します。
CASTEPのほとんどの用途では、最大の単一データは波動関数で、4次元の倍精度複素数配列として表されます。この4つの次元は平面波（Gベクトル）、バンド、k点およびスピンです。並列HPC環境では、現在CASTEPはk点、バンドおよびGベクトルに渡って波動関数を分散することが可能です。典型的な大規模CASTEP計算では、10kポイント未満あるいは1k点の場合もあり（フォノン計算の特定のクラスでは数1000のk点を必要とされます）、バンドは100-数1000オーダ、104-105のGベクトル、スピンは常に1または2です。波動関数は、CASTEPのチェックポイント処理の一部として”.check”ファイルとしてディスクへ書き込まれます。このファイルのサイズは数GBに達します。CASTEP計算中には、部分的に完了した点から回復可能なジョブを作成するため、またはさらなる解析のために、補助的な波動関数を含むファイルも利用されます。
波動関数のI/Oを実行するCASTEPのルーチンは、適切な名前の波動関数を読み書きします。CASTEPの現状の5.5リリースでは、ディスク出力はルートノードと呼ばれるプロセスにより行われます（内部的には、CASTEPは別々のノードで動作するプロセスを持ちますが、必ずしも物理的に別の計算ノード上で実行されているわけではありません）。各ノードは、その波動関数データをそのバンドグループ内のマスタに送信し、そのバンドグループはそのデータをそのGベクトルマスタに送信し、続けてそれをディスク出力用のルートノードに渡します。この操作は、全てMPI1対1通信を使用して行われます。
ここで、MPI-IOを使わない理由について議論します。CASTEPの.checkファイルは、ビッグエンディアンのバイトオーダーを使用する書式なしFortranファイルです。これは、CASTEPが使用されるあらゆる環境での移植性を提供するためです。これは、CASTEP開発者グループにより、.checkファイルの既存の形式との後方互換性が維持されることが指定されているためです。MPI-IO（またはNetCDFまたはHDF5）を使用すると、各MPIプロセスは.checkファイルに同時にアクセスできます。NetCDFとHDF5はアーキテクチャに依存しないファイルも提供します（MPI-IOはマシンに依存しないファイルを許可しますが、ベンダーはこれを実装することはほとんどありません）。しかし、上記の方法のいずれも書式なしFortranレコードと互換性がないため、既存のCASTEPの.checkファイルとの互換性はありません。
·実装
多くの場合、CASTEPジョブにおける最大の量を持つのはGベクトルです。このため、最初のプロトタイプとして、Gベクトル上のMPI_gatherを用いた波動関数出力に書き直しました。ここでの方法は、特定のk点とスピンにおける各バンドデータを収集した後、各バンドまたはバンドのブロックをGベクトルとバンドマスタの両方のノードに渡します。次に、データを出力のためルートノードに渡します。ベンチマークは、Geminiインターコネクトを備えたHECToRフェーズ2bで実行しました。ディスクI / Oに費やされる時間は約6.4秒です。384PEを用いて、この改良版は8.42秒府だったのに対し、CASTEP5.5は70.48秒掛かっていました。このテストケースは、5kポイント、40000Gベクトルおよび288バンドを含む酸化アルミニウム’2x2’スラブ（al2x2）です。実行にはGベクトルの並列分散のみを使用しました。コードは、既存の分析ツールと互換性のある正しい形式のCASTEP .checkファイルを生成して、3つの並列分布ストラテジーの全ての組み合わせで正確性がチェックされました。比較のために、al2x2システムでのCASTEPの基底状態SCF計算は、120PE（k点5並列とGベクトル24並列）で約1300秒掛かり、2回の波動関数出力呼び出しで約16秒が費やされていました。
同様に波動関数読込にも実装し、データがGベクトル上でMPI_scatterを用いて分散されるように書き換えました。また、パラレルデータの配布が変更された場合、データをどのように配布するかを決定する余分な機構も含まれています。 私たちの最初のプロトタイプの波動関数読込は、CASTEP 5.5よりも大幅に改善されました。しかしながら、この改良版は出力よりも4倍以上長い時間が掛かりました。
この非効率性の原因の一つとして、波動関数データを読み取るための内部配列の1つが、Gベクトルによるバンド（ブロック）として指定されていました。G-vectorsのバンドセット毎の余分なストライドを取り去るために、配列インデックスの順序を単純に切り替えて、Gベクトルが最初に来るようにすることでより効率的になりました。第2の最適化では、Gベクトル分散が実行間で変化した場合に、波動関数データを並べ替えるためのデータ処理を書き換えました。
最終的に、書き込みと同等の性能が得られました。
同様に、電子密度とポテンシャルに対応するルーチンがMPI集団通信を使用するように変更されました。これらはk点とバンドから独立しているため作業は単純です。
波動関数へ対称性を適用するルーチンは、フォノン計算に不可欠な部品です。波動関数を1つのk点セットから、対称操作によって関連する別の1つのk点セットに変換します。ここで予期しないバッファエラーを避けるため、対称操作を適用する前に、各バンドのデータに対してGベクトルを使ってMPI_gatherを用い、その後、データを適切なノードにスキャッターするように変更しました。
対称変換は、異なるノードに格納されたk点間にデータをマッピングする可能性があります。 この場合、集められたバンドデータは、そのk点を保持するノードに送信され、ここでは、スキャッターの前に対称操作が適用されます。
これにより、予期しないバッファに実行不能な量のRAMを割り当てることなく、大きなフォノン計算を実行できるようになります。 CASTEPデベロッパーズグループのPhil Hasnipの要請により、上記のルーチンを修正する際に学んだ事柄を波動関数の再割り当てにも適用されました。 このルーチンは、k点とバンド分散が変わらないと仮定して呼び出され、既存の波動関数からデータを取り出し、それを異なる平面波基底関数にマッピングします。これは主に、可変セル形状の最適化および分子動力学で使用されます。
これらの変更はCASTEP6.0としてリリースされました。
並列効率レポーティング
研究者が超並列HP??Cマシンでコードを実行する際に直面する困難の1つは、その並列性を効率的に活用することです。通常、これは事前に決定する手段はなく、既存の並行実行の効率を持って評価することもできません。異なるプロセッサ数での一連のベンチマーク実行を行うことで、並列効率を評価して、本番稼働のための有効なプロセッサ数を推定することは可能です。多少厄介ですが、このアプローチは多くのほぼ同一内容の実行を行う場合に有用です。しかしながら、その実行内で複数の手法が大幅に異なる場合は困難です。この問題は、複数の異なる並列化手法（FFT、バンド、kpoint）が同時に利用され、効率が通常のプロセッサ数の単調関数から大きくかけ離れている平面波DFT計算で特に深刻です。この作業のために、CASTEPの様々な操作を”communication”クラスと”calculation”クラスにグループ化し、内部タイミングデータを使用して並列実行効率レポートを実行毎に書き出すように修正しました。
さらに並列化を検討して、それ以上の最適化が提案できるかどうかを調べてレポートします。
これらの修正はCASTEP6.1でリリースされました。
バンド並列
バンド並列計算における大きなボトルネックは、バンド毎に変換行列を波動関数に適用することです。これらの変換でバンド並列処理を可能にした際には、Gベクトル並列に比べて2つの大きな欠点があります：
- 三重対角行列のサポートが無い：主要な変換は三重対角行列であり、これはGベクトルの並列計算で利用されますが、バンド並列計算では利用されていません。
- この変換はバンドグループ内のコア間でall-to-all通信が必要：このような通信は時間が掛かるだけでなく、n分割バンド並列計算ではn2でスケールします。
これらの2つの側面を最適化することが、優れたパフォーマンスを得るための鍵です。
·三重対角行列最適化
バンドセットが直交正規化されなければならない場合はいつも、変換行列は実際には三重対角です：これは、一般的なdgemmおよびzgemmでなく、dtrmmおよびztrmm BLASサブルーチンを使用するGベクトルの並列計算で利用され、パフォーマンスが大幅に向上しています。バンドはコア間でラウンドロビン方式で分配されます。局所的なバンド数がクライアントコアのバンド数と同じでない場合には、このオペレーションの最適化は比較的簡単です：この場合は単純なゼロパディングで簡単に処理できます。
·通信最適化
通信時間を改善するために、2つの大きな変更が実施されました。最初に、オリジナルの素朴なコミュニケーションパターンをシストリックループ（リングトポロジー）に置き換えました。第2に、ブロッキング同期通信を非ブロッキング非同期通信に置き換えました。
シストリックループの最初の実装では性能は良くありませんでした。シストリックアルゴリズムは本質的に同期的であるため、最長の通信によって速度が制限されるためです。
パフォーマンスを向上させるために、収縮期ループを並べ替えて、隣接ノード間の平均距離は増加するが、最長距離は減少するようにしました。こうして、シストリックループの各通信フェーズは高速化されました。
この修正はCASTEP7.0でリリースされました。
謝辞
このプロジェクトは、nAG Ltd.が運営するHECToRの分散計算科学および工学(CSE)サービスの基に実行されました。英国の国立スーパーコンピューティング・サービスである、HECToR：英国リサーチ・カウンシル・ハイエンド計算サービスは、リサーチ・カウンシルを代行するEPSRCが管理しています。そのミッションは英国学術界の科学および工学の研究支援です。HECToRスーパーコンピューターは、UoE HPCx Ltd.およびnAG Ltd.のCSEサポートサービスにより管理運営されています。
文献
| [1] | http://www.castep.org/ |
| [2] | http://www.hector.ac.uk/cse/distributedcse/reports/castep/ |
| [3] | http://www.hector.ac.uk/cse/distributedcse/reports/castep02/ |
| [4] | http://www.hector.ac.uk/cse/distributedcse/reports/castep03/ |
| [5] | http://www.hector.ac.uk/cse/distributedcse/reports/castep-geom/ |