Ning Li, HECToR CSE Team
概要
乱流および化学反応シミュレーションコード"SoFTaR"は、ブルネル大学で開発された、ジェット流の乱流と反応の直接数値シミュレーション(DNS)コードで、TU/e(オランダ・アイントホーフェン工科大学)において開発されたリアリスティックな化学反応に基づくDNSのための、燃焼化学向け火炎面発生マニホールド・データベースとリンクしています。SoFTaRは現在進行中の研究EPSRC grant EP/G062714/1 "Clean Coal Combustion: Burning Issues of Syngas Burning" (PI: Dr Xi Jiang; PDRA: Dr George Siamas)で用いられています。
CSEチームは、この研究グループのHECToRにおける大規模シミュレーション開始前におけるコードの最適化を依頼されました。CSEチームは現地に赴き、研究者にハンズオントレーニングを実施しました。続いてCSEチームが直接コードの最適化を実施しました。性能のボトルネックが特定され、新しい通信ルーチンが実装され、ある現実的なテストケースにおいてこのコードは5倍の高速化が達成されました。その他に並列I/Oの取り扱いについての示唆も得られました。本レポートではこれら最適化の詳細について報告します。
通信コードの最適化
このアプリケーションは構造メッシュおよびコンパクトスキームの有限差分法を用いています。高負荷の計算を高速アルゴリズムを用いてローカルメモリーにおいて行うために、一次元領域分割がグローバルデータの置き換えに用いられます。残念ながらこのコードの通信ルーチンは、下記のCRAY PATレポートが示すように、HECToRのような現代的なスーパーコンピューターに即したものではありませんでした。
Time % | Time | Imb. Time | Imb. | Calls |Group
| | | Time % | | Function
| | | | | PE='HIDE'
100.0% | 622.380772 | -- | -- | 10590767.6 |Total
|-------------------------------------------------------------------
| 76.5% | 475.970683 | -- | -- | 10213591.6 |MPI
||------------------------------------------------------------------
|| 58.4% | 363.761574 | 149.615814 | 29.4% | 5084341.8 |mpi_send_
|| 17.6% | 109.648667 | 283.128510 | 72.7% | 5084341.8 |mpi_recv_
||==================================================================
| 13.2% | 82.433108 | 324.558243 | 80.4% | 44904.0 |MPI_SYNC
| | | | | | mpi_barrier_(sync)
| 10.3% | 63.976981 | -- | -- | 332272.0 |USER
||------------------------------------------------------------------
|| 2.5% | 15.512290 | 0.743604 | 4.6% | 1347.0 |rhs_
|| 1.7% | 10.337003 | 1.738476 | 14.5% | 22453.0 |swapdat_
|| 1.6% | 10.099456 | 1.762906 | 15.0% | 17511.0 |swapinv_
|| 1.2% | 7.647495 | 0.311883 | 3.9% | 38614.0 |dx_
|===================================================================
見ての通りに、コードの通信部分(MPI+MPI_SYNC)は全実行時間の89.7%を占めていました。さらなるコード分析により、グローバルデータの置き換えがALLTOALL型ではなく、顕なMPIブロッキング・センド/レシーブにより実装されていることが解りました。ユーザーは自身の手で結果的にはMPI_ALLTOALLを実装していたのです。これはHECToRでは効果的ではなく、専用の高度に最適化されたALLTOALLルーチンを用いるべきです。MPI_ALLTOALLを用いて2つの通信ルーチン(上記テーブルのswapdatおよびswapinv)を書き換えたところ、下記に示すCRAY PATレポートのように、大きな高速化が得られました。
Time % | Time | Imb. Time | Imb. | Calls |Group
| | | Time % | | Function
| | | | | PE='HIDE'
100.0% | 113.863253 | -- | -- | 519839.6 |Total
|---------------------------------------------------------------
| 44.2% | 50.355772 | -- | -- | 102699.6 |MPI
||--------------------------------------------------------------
|| 33.0% | 37.576854 | 2.345243 | 5.9% | 39964.0 |mpi_alltoall_
|| 9.0% | 10.273081 | 9.488242 | 48.4% | 8913.8 |mpi_recv_
|| 2.1% | 2.441814 | 0.093033 | 3.7% | 44904.0 |mpi_barrier_
||==============================================================
| 40.5% | 46.121814 | -- | -- | 332272.0 |USER
||--------------------------------------------------------------
|| 13.5% | 15.378509 | 0.663161 | 4.2% | 1347.0 |rhs_
|| 6.7% | 7.639985 | 0.350639 | 4.4% | 38614.0 |dx_
|| 3.8% | 4.339009 | 4.312641 | 50.2% | 1.0 |exit
|| 3.3% | 3.742230 | 0.134771 | 3.5% | 8082.0 |d2x_
|| 1.4% | 1.614176 | 0.063646 | 3.8% | 40410.0 |dz_
|| 1.4% | 1.608269 | 0.073636 | 4.4% | 46696.0 |thomax3d_
|| 1.3% | 1.509728 | 0.035236 | 2.3% | 8082.0 |d2z_
|| 1.3% | 1.456928 | 0.175116 | 10.8% | 22453.0 |swapdat_new_
|| 1.2% | 1.400617 | 0.077870 | 5.3% | 38165.0 |dy_
|| 1.2% | 1.309752 | 0.009497 | 0.7% | 48492.0 |thomaz3d_
|| 1.1% | 1.249496 | 0.025782 | 2.0% | 1.0 |MAIN_
|| 1.1% | 1.243370 | 0.013231 | 1.1% | 46247.0 |thomay3d_
|| 1.0% | 1.169883 | 0.174941 | 13.1% | 17511.0 |swapinv_new_
||==============================================================
| 15.3% | 17.385667 | -- | -- | 84868.0 |MPI_SYNC
||--------------------------------------------------------------
|| 11.6% | 13.243273 | 2.823314 | 17.7% | 44904.0 |mpi_barrier_(sync)
|| 3.6% | 4.142394 | 0.951367 | 18.8% | 39964.0 |mpi_alltoall_(sync)
|===============================================================
まず最初に、この新しいコードのMPI関数部は、558秒から68秒へと以前に比べ8.2倍高速化しました。最も高負荷なルーチン(上記テーブルのUSER部です)は、rhs(方程式の右辺の構築を行う)やdx(微分計算)などですが、これらの実行時間は以前と変わらずほぼ同程度です。しかしながら通信ルーチンの非MPI部(swapdat_newおよびswapinv_new)はさらにコストが減っています。何故ならMPI_ALLTOALLのセンド/レシーブバッファのパッキングにおいてより好ましいメモリーアクセスが生成されているためです。これにより18秒の実行時間の削減が生じています。以下は旧コードの例ですが、センドバッファfsendが大きなメモリーストライドで代入されているため(2番目の次元kがループ最内側で変化する)キャッシュ効率が低いものとなっています。
do i=1,nx
do j=1,nyblk
jj=j+jshift
do k=1,nzblk
fsend(i,k,j)=f(i,k,jj)
end do
end do
end do
下記は新しいコードの例で、MPI_ALLTOALLのセンドバッファsend_bufはより好ましい形に変更されています(メモリーを連続的に更新している)。
do j=1,nyblk
do k=j1,j2
do i=1,nx+2
send_buf(pos)=f(i,k,j)
pos=pos+1
enddo
enddo
enddo
これらの例で示したように、科学研究に直接関係するものではありませんが、HPCにおいてはどのようにコード化するかが極めて重要です。これらの変更は幸いにも、同じインターフェイスの新しい関数と単純に入れ替えることが出来たため、ブラックボックス的に変更が可能でした。
実行時間とクァッドコアでの性能
このセクションで示す実行時間は２つの中規模シミュレーションでの結果です： 一つは128^3メッシュを用いて128コアで実行した場合、そしてもう一つは128*256^2メッシュを用いて256コアで実行した場合です。これら二つのケースはHECToR上で数分しか掛かりませんが、研究に用いる場合と同等のコアに対する負荷を持つ典型的な実行ケースです。
以下のテーブル(テストケースの問題サイズは任意で良く、重要なのは高速化の割合です)は、通信ルーチンを最適化した新しいコードが、旧コードより5倍高速であることを示しています。コア数は増えるに従い、ALLTOALL通信が占める割合がより高くなり、その利点がさらに明らかになっています。ただし、本レポートが作成された時点(October 2009)において、クアッドコアプログラミング環境はHECToRでロードされていません。よってクアドコアハードウェア向けの最適化とやや優れたパフォーマンスを得るために，アプリケーションのコンパイルの前に「xtpe-barcelona モジュールのロード」が必要です。
| No. core | Old code | New code | New code (xtpe-barcelona module) |
speed-up |
| 128 | 622 | 112 | 105 | 5.9 |
| 256 | 4301 | 662 | 6.5 |
このアプリケーションは通信が主要であるため、各クアッドコアノードで2コアのみを用いることによる、20%程度の実行時間削減のさらなる性能向上が可能です。
その他の改善策
- 二番目のCRAY PATレポートにあるように、この新しいコードはMPI_RECVに9%の時間が掛かっています。ここでのデータ交換通信は実計算ではなく、I/Oを処理するプロセッサーにデータを収集するためのものです。この部分は良い実装がされていません。このアプリケーションのデータ構造は極めて単純(3次元カルテシアンメッシュ)であるため、MPI-IOを実装してI/O性能を向上させて、I/O処理を除去することは容易に可能です。
- 現状の通信アルゴリズムは、シミュレーションで利用可能なコア総数を、y方向とz方向両方においてメッシュ点の数かあるいはそれ以下に制限しています。将来大規模なDNSシミュレーションを行う際に、この通史鳴子リズムを2次元領域分割を用いるように更新する必要が生じるでしょう。本レポートの著者は、このようなライブラリーを他のCFDアプリケーションをサポートするdCSEプロジェクトで開発しています。SoFTaRグループは将来、このdCSEの結果を利用することが可能でしょう。