計算技術科学特論B2020

1. P.
電子動力学アプリケーションの最適化2
120/7/9計算科学技術特論B
廣川 祐太
筑波大学計算科学研究センター
免責事項
• 富岳共用前評価環境における評価結果は、スーパーコンピュータ『富岳』
の共用開始時の性能・電力等の結果を保証するものではない

2. P.
講義内容
1日目: アプリケーションとメニーコアシステムにおける性能評価
1. 実空間差分法に基づく電子動力学シミュレーション
2. 電子動力学アプリケーションSALMON
3. Xeon PhiプロセッサにおけるWide SIMD・メニースレッドへの最適化
4. Oakforest-PACS全系を用いたMulti-scaleMaxwell+TDDFT計算の性能評価
2日目: スーパーコンピュータ「富岳」の活用と計算 (機) 科学のコデザイン
1. スーパーコンピュータ「富岳」における最適化
2. 富岳を用いたSingle-scale Maxwell+TDDFT計算の性能評価
3. 計算科学におけるオープンソースソフトウェア (OSS) 開発 + トラブル集
2020/7/2計算科学技術特論B 2

3. P.
スーパーコンピュータ「富岳」
における最適化
20/7/9計算科学技術特論B 3

4. P.
今回の最適化対象
• Single-scale Maxwell-TDDFT simulation
• 同じ空間スケール (実空間グリッド) でMaxwellとTDKSを解く
• したがってTDKS方程式のサイズは前回より非常に大きくなる
• 電磁界解析を組み合わせた多原子・多電子の大規模シミュレーションを実現できる
• 計算の規模は対象の原子数・電子数に比例する
• 最大値でおおよそ1万原子 + 7万電子 (軌道の数は4万)
• 実空間グリッドは (512, 256, 256) 程度
20/7/9計算科学技術特論B 4

5. P.
再掲: 計算と通信の性質
SUM (orbital) MPI_Allreduce(DP vector)
Stencil 25-points stencil (DP complex)
Halo Halo communication
FFT 3-D FFT by FFTE
NL-PP SpMV-like calculation
20/7/9計算科学技術特論B 5
𝝍 𝒃(𝒓, 𝒕) Wave function (Electron orbital)
𝝆(𝒓, 𝒕) Charge density of electrons
𝑽 𝑯(𝒓, 𝒕) Hartree potential (Poisson equation)

6. P.
計算と通信の最適化
• 25点ステンシル計算が大部分を占める
• これまでもXeon Phi (KNC, KNL) を中心に512-bit SIMD最適化
• ref. Vol. 2018-HPC-163 No. 23, Vol. 2019-HPC-168 No. 4
• 従来は 163 といった短いループ長が対象
• 現在は 643, 1283 など一般的なサイズ
• 富士通コンパイラ向けに最適化
• 通信は6−8個のサブコミュニケータで制御
• 計算対象の波動関数は4次元系
• 3次元ネットワーク (Tofu-D) への適切なMPIプロセスマッピングが必要
620/7/9計算科学技術特論B

7. P.
コード最適化: ステンシル計算
do ib = 1,Norbital ; do iz = 1,Lz; do iy = 1,Ly
! initialize
do ix = 1,Lx
htpsi(ix,iy,iz,ib,ik) = &
(V_local(ix,iy,iz,ib,ik) + lap0(ik)) &
* tpsi(ix,iy,iz,ib,ik)
end do
! compute X-difference
do ix = 1,Lx ; ... ; end do
! compute Y-difference
do ix = 1,Lx ; ... ; end do
! compute Z-difference
do ix = 1,Lx ; ... ; end do
end do; end do; end do
• SIMD + SWP最適化を適用する
• SWP: SoftWare Pipelining
• Loop unroll
+ Loop scheduling
+ Improve instruction-level parallelism
• 命令レイテンシが比較的長く隠蔽が重要
• FADD, FMAD: 9 cycle
• ref. https://github.com/fujitsu/A64FX
• ループ中のレジスタ使用量を減らす
• ループボディを短くすることになる
20/7/9計算科学技術特論B 7

8. P.
再掲: MPIによる並列化方法
• 複数のMPIコミュニケータで通信を局所化
2020/7/2計算科学技術特論B 8
comm_rx
comm_ry
atom i
comm_ai
comm_aj
comm_rgrid
comm_rz
Ψ1,2,3(r) Ψ4,5,6(r) Ψ7,8,9(r) …
comm_orbital
atom j
Communicator
comm_orbital 軌道方向を束ねる
異なる軌道
同じ 実空間 を計算するプロセス群
comm_rgrid 実空間方向を束ねる
同じ 軌道
異なる実空間 を計算するプロセス群
comm_rx, ry, rz comm_rgrid内で各軸の通信
comm_ai, aj i, j番の原子に相当するグリッドを持
つMPIプロセス

9. P.
通信最適化: Tofu-DへのMPIプロセスマッピング (1)
• 波動関数は (x, y, z, w) の4次元
• 実空間: comm_rgrid (x, y, z)
• 電子軌道: comm_orbital (w)
• 実時間発展計算
• comm_rgridの通信が中心
• 同通信 (halo + collective) のホップ
数が最小となるようにネットワーク
へのマッピングが必要
20/7/9計算科学技術特論B 9
comm_rx
comm_ry
atom i
comm_ai
comm_aj
comm_rgrid
comm_rz
Ψ1,2,3(r) Ψ4,5,6(r) Ψ7,8,9(r) …
comm_orbital
atom j

10. P.
通信最適化: Tofu-DへのMPIプロセスマッピング (2)
• Tofu-Dは3次元ネットワークとして見える
• 4 MPI process/nodeが推奨される
1. 4次元系をどのように3次元MPIプロセス空間にマッピングするか
➢ 3次元系 + 1次元系としてプロセス形状を作る
2. ノード内の複数MPIプロセスをどう扱うか
➢ 3次元MPIプロセス空間のどこかの軸に割り当てる
1020/7/9計算科学技術特論B

11. P.
通信最適化: Tofu-DへのMPIプロセスマッピング (3)
19
27
20
28
23
31 32
24
17
25
18
26
21
29 30
22
1
9
2
10
5
13 14
3
11
4
12
7
15 16
6 8
Compute node (4 process per node)
Ty
Tz
Tx
20/7/9計算科学技術特論B 11
(Tx, Ty, Tz) 3-D node shape
Pall Total # of process
(Prx, Pry, Prz) # of proc. / spatial grid
Porbital # of proc. / orbital
Pnode = 4 # of proc. / node
1. Prx, Pry, Prz, Porbitalを決定する
2. Porbitalを3変数の積 (Pox, Poy, Poz) に変形する
3. (Prx×Pnode, Pry, Prz) と積をとって (Tx, Ty, Tz) とする
comm_rgrid

12. P.
富岳を用いたSingle-scale
Maxwell+TDDFT計算の性能評価
20/7/9計算科学技術特論B 12

13. P.
性能評価: 富岳共用前評価環境
Fugaku
Processor Fujitsu A64FX (based on Arm v8.2-a)
Compute core 12 physical cores (core memory group, CMG)
with 4 CMGs = 48 physical cores with 2 GHz
Cache L1D$: 64 KiB, L2$: 8 MiB (CMG shared)
Memory 32 GiB: HBM2 (High bandwidth memory)
SIMD instruction Arm SVE with 512-bit
Theoretical peak
performance
3072 GFLOPS
Evaluated system 27,648 node, 84.935 PFLOPS
Network Tofu-D (6-dimensional mesh/torus)
1. 単体ノード性能
• ステンシル計算
• アプリケーション全体
2. Weak scalingの評価
• 波動関数のサイズを固定
• (54, 48, 40, 123.34)
• 5 GB/process (20 GB/node)
• ノード数4倍でスケール
• 問題規模を2倍にするために、実
空間と軌道のサイズを両方2倍に
しなければならない
20/7/9計算科学技術特論B 13
免責事項
• 富岳共用前評価環境における評価結果は、スーパーコンピュータ『富岳』
の共用開始時の性能・電力等の結果を保証するものではない

14. P.
単体ノード性能
20/7/9計算科学技術特論B 14
• Auto vect. + SWPで322.7 GFLOPSを達成
• SWPの有無で1.4−5倍の性能差
• 約10.5%の効率
• HBM2のメモリバンド幅から計算したルーフラインに
ほぼ一致する性能
• 実効メモリバンド幅は866 GB/s
• 約84.5%の効率
• TDDFT計算全体の性能は321.6 GFLOPS
• ほぼステンシル計算の性能に律速
Auto vect. コンパイラによるベクトル最適化
Auto vect. + SWP + Software pipelining最適化
Hand vect. 512-bit SVEの手動ベクトル最適化

15. P.
Weak scaling (1)
• 1反復あたりの実行時間
• 実行効率は73.4%まで低下
• 線形低下の傾向がある (約11%ずつ)
• 150kノードで56%前後 (約1.5 sec/iter.)
• 効率を落としている原因はなにか
• 積み上げグラフで調べる
20/7/9計算科学技術特論B 15

16. P.
Weak scaling (2)
20/7/9計算科学技術特論B 16
• 各ルーチンの実行時間の積み上げ
• 各ルーチンで費やした通信時間を併記
• 通信/計算オーバーラップはしていない
• Hartreeがボトルネック
• 実空間プロセス (comm_rgrid) で閉じたFFT
• 最大96ノード (384プロセス) の計算
• FFTEを用いた3次元FFT、2次元(Y, Z) 分割
• 全体は3次元プロセス分割で計算
• 1,728 -> 6,912でX軸の格子点数が2倍になる
• MPI_Alltoallのメッセージ長が増加し、
通信時間が2倍に単純増加

17. P.
再掲: MPIによる並列化方法
• 複数のMPIコミュニケータで通信を局所化
2020/7/2計算科学技術特論B 17
comm_rx
comm_ry
atom i
comm_ai
comm_aj
comm_rgrid
comm_rz
Ψ1,2,3(r) Ψ4,5,6(r) Ψ7,8,9(r) …
comm_orbital
atom j
Communicator
comm_orbital 軌道方向を束ねる
異なる軌道
同じ 実空間 を計算するプロセス群
comm_rgrid 実空間方向を束ねる
同じ 軌道
異なる実空間 を計算するプロセス群
comm_rx, ry, rz comm_rgrid内で各軸の通信
comm_ai, aj i, j番の原子に相当するグリッドを持
つMPIプロセス

18. P.
考察: 達成性能の妥当性 (1)
• Byte/FLOPから算出できる期待性能 (通信コストを含まず)
• 支配的なステンシル計算 : 2.68 Byte/FLOP
• システムが提供する値 : 0.33 Byte/FLOP (1024 GB/s ÷ 3072 GFLOPS)
• ピーク性能比 : 0.33 / 2.68 ≒ 12.4%
• メモリバンド幅律速のため、ピーク性能に対して十分な性能とは言えない
1820/7/9計算科学技術特論B
[PFLOPS] Theoretical
peak
Estimated Actual
(vs. Estimated)
432 1.327 0.165 0.057 (34.5%)
1,728 5.308 0.661 0.219 (33.1%)
6,912 21.234 2.646 0.773 (29.2%)
27,648 84.935 10.583 2.692 (25.4%)

19. P.
考察: 達成性能の妥当性 (2)
• 要求されるシミュレーション性能から検証
• 物質構造やレーザー強度といった複数のパラメータでの計算が必要
• パラメータあたり1日で処理できることが望ましい
• パラメータあたり最大10万反復程度、1 sec/iter.で約27.8時間
• 27,648ノードの1.13 sec/iter.は、要求に対し十分な性能が得られている
• 計算可能な系の規模から検証
• 27,648ノードで1.3万原子系の電子動力学計算が可能
• 単純見積もりでは、富岳全系により2−3万原子系を計算可能
• 計算の規模は4倍だが、系の規模は2倍で増加するため
1920/7/9計算科学技術特論B

20. P.
考察: 達成性能の妥当性 (3)
• Sequoia BG/Q全系でのTDDFT計算 (Draeger, et. al.: IEEE Cluster 2016)
• FLOPSでは、BG/Qが43%以上の高い効率を示している
• Draegerらは(D/Z)GEMM中心に実装、FLOPSでは高く見える
• 我々はstraightforwardに実装し、ステンシル計算が中心
• Time-to-Solutionでは、我々は高速な手段を実装している
• BG/Qの結果を富岳と同規模までStrong scalingで計算したとすると12.5 sec/iter.
• 計算した系の規模は2倍以上、我々の手法は20倍以上の性能を実現している
2020/7/9計算科学技術特論B
Peak perf. Achieved perf. Time/iter. Problem size Dominant kernel
Sequoia BG/Q 20 PFLOPS 8.6 PFLOPS 53.2 sec 5400 atom (D/Z)GEMM
Fugaku 85 PFLOPS 2.692 PFLOPS 1.13 sec 13632 atom Stencil

21. P.
まとめ
• 光科学ソフトウェアSALMONを富岳に向け最適化、性能評価
• ステンシル計算は実効メモリバンド幅866 GB/s (84%) を達成
• Weak scalingは75−95%の実行効率を達成
• 0.8−1.13 second/iterationの計算性能、既存研究に比べ20倍以上の性能を実現
• プロダクトランに十分な性能を達成している
• 富岳全系を用いた超大規模シミュレーションに向けて
• FFTの性能低下:
• 全系実行でも128−192ノードで閉じた計算のため、まだ耐えられる
• メモリ不足の可能性
• 60−75%程度のメモリを使用 (20 GB/node)、問題全体との比例関係が見えている
2120/7/9計算科学技術特論B

22. P.
計算科学におけるOSS開発
20/7/9計算科学技術特論B 22

23. P.
SALMONの開発について
• 独立に開発していた2つのアプリケーション (ARTED, GCEED) を統合、
広範なシミュレーションをひとつのソフトウェアとして提供するのが目的
• ARTED: 筑波大学、GCEED: 分子科学研究所
• どちらも非公開で開発、利用されていたが、広範なユーザに活用してもら
うためにはOSSの提供が必須
• SALMONはどのようにOSSで開発していったか、どのような意思決定を
したかを紹介
20/7/9計算科学技術特論B 23

24. P.
OSSでの開発について (1)
• どう共同開発していくか
• 複数人でコードを開発、バグを埋め込んだり破綻しないように管理する必要がある
• バージョン管理手法 (git, svn, mercurial) はMUST
• コードの分散管理、最も一般的という理由でgitを選択
• コードの共有方法
• ウェブで提供されているリポジトリホスティングサービスを使うか (ex. Github)
• 独自にホスティングサーバを建てるか (ex. Gitlab)
• ホスティングサーバの管理 (セキュリティ・保守) の観点からGithubを活用
20/7/9計算科学技術特論B 24

25. P.
OSSでの開発について (2)
• ビルド方法をどうするか
• マルチプラットフォーム (スパコン、クラスタ、ラップトップ) 対応は非常に困難
• CMakeを用いてユーザの環境に適したビルド環境を構築できるように、かつビル
ド環境の保守性を向上させる
• ソフトウェアテストの導入
• 様々なシミュレーションを提供するソフトウェアの特性上、各開発者の変更がどこ
に影響を与えているか確認するのが難しい
• ソフトウェアテストはどうしても導入が必要な機能であると強く推進
20/7/9計算科学技術特論B 25

26. P.
どう共同開発していくか
• gitによる管理
• 変更 (機能追加・バグ修正) をそれぞれ別の作業 (ブランチ) として管理可能
• 作業内容の差分表示、各作業履歴 (コミット) 表示、コミット取り消し等が可能
• バグが起きたときにコミットをさかのぼってどこで発生したのかを確認できる
20/7/9計算科学技術特論B 26

27. P.
コードの共有方法
• ソースコードのリポジトリ (コミット情報全体) をどう管理するか
• Github, Bitbucketなどのウェブホスティングサービス
• Gitlab, Gerritなどのオンプレミスでの管理
• プライベートリポジトリ (非公開) で開発を行いたい
• 後にパブリックにするが、中途半端なものはプライベートにしておきたい
• リポジトリ管理サーバの管理コストは避けたい
• 常に管理できる人が確保できればよいが…
• 両方を満たし知名度の高いGithubを利用することに
20/7/9計算科学技術特論B 27

28. P.
Githubのリポジトリページ
20/7/9計算科学技術特論B 28
https://github.com/SALMON-TDDFT/SALMON2

29. P.
ビルド方法をどうするか
• 何かしらのビルド基盤は導入する必要があった
• マルチシステム (スーパーコンピュータ、PCクラスタ、ラップトップ) への対応
• ユーザごとに環境が異なるPCクラスタやラップトップの対応は特に難しい
• 必要な機能
• BLAS/LAPACK/ScaLAPACKなどサードパーティ製ライブラリの検索
• MPIコンパイラやOpenMPフラグなど検索
• Fortranのソースファイルを正しい順序でコンパイルできること
• メンテナンス性
• Autotools (configure + make) よりメンテナンスしやすいCMakeを選択
20/7/9計算科学技術特論B 29

30. P.
CMake
• OSSのビルド自動化ツールチェイン
• Linux distribution, macOS, Windowsなどクロスプラットフォーム対応
• シェルスクリプトライクなautotoolsより圧倒的に書きやすい
• 色々な機能を実現するためにはかなり苦労する
• SALMONのCMake
• サードパーティ製ライブラリの自動ビルド
• コンパイルフラグの自動検索
• コンパイラ機能の自動検証
• クロスコンパイル (主にスーパーコンピュータ向け) の提供
20/7/9計算科学技術特論B 30
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(hello)
add_executable(a.out main.c sub.c)
$ cmake .
$ make

31. P.
ソフトウェアテストの導入
• ソフトウェアの動作が正しいことを証明するためのテスト
• ソースコードの変更が、動作に影響を与えないことを保証する
• 特に複数人が関わる開発では、意図しないバグの混入リスクは高い
• シミュレーションソフトウェアにおけるテストの正解とは？
• クラッシュせずプログラムが正しく終了する
• 出力されるはずのファイルが正しく出力される
• 計算結果が正しい → どの水準で？最適化によって演算誤差は変わる
• 「計算結果が正しい」の定義をよく議論する必要がある
20/7/9計算科学技術特論B 31

32. P.
シミュレーションソフトウェア特有の難しさ
• シミュレーションが正しいことを証明するには計算しないといけない
• それなりの計算時間が必要になってくる
• ソフトウェアのテストが数時間かかるというのは非常に困る
• 問題サイズが小さく、かつ効率よくバグ検出可能にする
• 大規模実行でないと発生しないバグも存在するが、そこは目をつぶる
（それらまでカバーすると一度のテストに数時間かかってしまう）
• SALMONはXeonの1ノードなら2分〜8分程度で全34テストを処理
20/7/9計算科学技術特論B 32

33. P.
SALMONの現在の開発体制
20/7/9計算科学技術特論B 33
1. ラップトップやリ
モートの計算機資源で
ソースコードを更新
2. Githubに送る
(push, pull request)
4. テスト用サーバ
が変更をダウンロー
ドして自動テスト
6. テストが通って
いることを確認
8. 各ユーザが変更を
ダウンロード (pull)

34. P.
トラブル集
20/7/9計算科学技術特論B 34

35. P.
特定のシステムで時間発展計算の結果が狂う
• 結果が狂う → 本来保存される実空間領域中の電子数が保存されない
• 特定のMPI処理系・バージョンでMPI_Iallreduceのバグを踏んでいたた
め、これを使った最適化実装に計算結果不整合が生じていた
• 別の環境で実行し、違いを揃えて原因を特定すること
• 使用しているライブラリにバグがあることも
• とくにコンパイラのバグによって発生することが多い（個人の経験則）
20/7/9計算科学技術特論B 35

36. P.
MD計算をするとクラッシュ (SEGV) する
• サブルーチンの引数が不足していてNull pointer accessが発生していた
• Fortranはmoduleに入っていない外部サブルーチンのCalleeの引数チェックを行わ
ないため、目視でのチェックを要した
20/7/9計算科学技術特論B 36
subroutine update_MD_step(a, b, c, d, e, f, g, h, i, j, k, l)
...
end subroutine update_MD_step.f90
do it=1,nt
...
call update_MD_step(a, b, c, d, e, f, g, h, i, j, k)
...
end do time_evolution.f90

37. P.
基底状態計算の収束回数が実行のたびに変化する
• 同じパラメータ・環境で実行 → 同じ結果が得られるはず
• 最短と最長の反復回数に2倍以上の差は生じているが、実際に得られた結
果（基底状態）はどちらも正しいものが得られている
• OpenMP reductionの非決定性 (non-deterministic) によって、冗長計算
の結果に誤差が発生していた
20/7/9計算科学技術特論B 37

38. P.
Hartree potentialの冗長計算
• comm_rgridでhartree potentialを冗長
計算している
• comm_orbitalのランク数分の冗長計算
• 電子密度から陰的に求められ、未知数は
実空間グリッドのサイズに相当
• 未知数はMPIプロセス数に対して小さい
• 2563の問題サイズを27648ノードで解くのは
通信コストが高すぎる
• 系により解き方が違う
• 孤立系: CG (Conjugate Gradient)
• 周期系: FFT
20/7/9計算科学技術特論B 38
comm_rx
comm_ry
atom i
comm_ai
comm_aj
comm_rgrid
comm_rz
Ψ1,2,3(r) Ψ4,5,6(r) Ψ7,8,9(r) …
comm_orbital
atom j

39. P.
CG (Conjugate Gradient) 法
• 連立一次方程式 Ax = b を解く反復法
• OpenMP reductionは係数α, βおよび残差ノルムで取る（ベクトルの内積）
• CG法もFFTも、各冗長計算の結果がすべて一致している必要がある
20/7/9計算科学技術特論B 39

40. P.
OpenMP reductionの実装方法
• omp reduction(operator:var)
• 各スレッドで変数varを持ち、最後にスレッド間の結果をoperatorで畳み込む
• 一般的にはatomic命令 (排他制御命令) で性能重視の実装が採用される
• GCC/LLVM/Intelは最もベーシックにはatomic命令実装と推察される
• atomic命令は演算順序が保証されない
• 計算が完了したスレッドからreductionを実行する
• OSのコンテキストスイッチや、演算コアの周波数などにより差が生じる
20/7/9計算科学技術特論B 40

41. P.
演算順序を保証するために
• omp reductionを手動で実装する
• 演算誤差が必ず一意に定まるように → すべての冗長計算の結果が一致
20/7/9計算科学技術特論B 41
integer,intent(in) :: n
real(8),intent(in) :: x(n), y(n)
real(8),intent(out):: ret
integer :: i
ret = 0d0
!$omp parallel do reduction(+:ret)
do i=1,n
ret = x(i) * y(i)
end do
real(8) :: reduce_work(0:omp_get_max_threads()-1)
integer :: tid
reduce_work = 0d0
!$omp parallel private(i,tid)
tid = omp_get_thread_num() !thread ID
!$omp do
do i=1,n
reduce_work(tid) = reduce_work(tid) + x(i) * y(i)
end do
!$omp end do
!$omp end parallel
ret = sum(reduce_work)