2.1 圧縮性流体解析プログラムによる FX100 の性能評価と高速化チューニング
宇宙航空研究開発機構 宇宙科学研究所
高木亮治

2.1.1 はじめに
JAXA で開発を行っている三次元圧縮性流体解析プログラム UPACS1)はステンシル系プログラムである。
ここでは UPACS から機能を最低限に絞り込んだカーネルプログラム UPACS-Liteを用いて FX100 の性能評価ならびにチューニングを実施したのでその結果について紹介する。
2.1.2 UPACS-Lite
UPACS-Lite は JAXA が開発している実用的な UPACS の機能を絞り込んで性能評価や高速化
チューニングを実施するためのカーネルプログラムである。UPACS-Lite では対流項は MUSCL＋SHUS、時間積分は 2 時精度 Euler 陰解法とし、MFGS で内部反復を 2 回、MFGS のスレッド
並列化には Block Red-Black 法を利用、乱流モデルはなしの粘性計算、並列化は MPI と OpenMPを用いたハイブリッド並列としている。
UPACS-Lite では、支配方程式を有限体積法で離散化した離散方程式を解くことになるが、その際の主要な構成要素としては、時間積分（左辺）、対流項、粘性項が存在する。それぞれの計算は全てステンシル計算となるが、図 １で示すようにステンシルの形（メモリアクセスパターン、量）や演算パターン・量が異なる。

図 １

UPACS-Lite で使われるステンシル

また、UPACS では図 ２で示すように複数ブロックの構造格子を用いているため、通常の計算ではブロックの大きさや形が異なり、その結果プログラム中では様々なループ長、特にインデックス毎にループ長が異なることになり、高速化の際に注意する必要がある。

1 / 253

図 ２

複数ブロックの構造格子をデータ構造にマッピング

2.1.3 測定環境
FX100（JAXA の JSS2）を用いて性能評価を行った。表 1 に FX100 の諸元を示す。
表 1

マシン

測定環境（JAXA の FX100、一部に推定値あり）
SORA-MA（FX100）

SORA-PPPRIMEHPC FX100

PRIMERGY RX350S8

TM

CPU

Fujitsu SPARC64 XIfxIntel Xeon E5-2643V2

周波数1.975GHz

3.5GHzCPU/ノード

1

2

コア/CPU32

6

コア/ノード

32

12

理論性能

1.011TFLOPS

0.336TFLOPS

メモリ性能

431GB/s

119.4GB/s

コンパイルオプション-Kfast, parallel, openmp, noalias=s、 -O3 -parallel -openmp -fastarray_private, preex, ocl, XFILL -Qt-x-

2.1.4 測定結果
2.1.4.1

スレッドスケーラビリティ

ノード内スレッド並列性能のスケーラビリティを測定した結果を図 ３に示す。ここでは問題規模を一定にしたストロングスケーリングの性能を評価している。ブロックサイズを増やす事で並列性能が向上していることがわかる。また 80%を目安と考えると 8 スレッドまでは十分な効率が出ていると判断した。図 ３a)はデフォルトの状態、 図 ３b)は実行時の

2 / 253オプションでインターリーブを用いた場合を示す。インターリーブを用いることで 1 スレ
ッドの性能が悪化する。そのため多スレッドの性能は見かけ上向上する。

a) defaultb) interleave

図 ３ ノード内スレッドスケーラビリティ
2.1.4.2

ハイブリッド並列

ハイブリッド並列の評価結果を図４に示す。

図 ４ ハイブリッド並列 vs フラット MPI

3 / 253

1 ノードの結果でノードに割り当てるブロックサイズを 403、803、1603とした。ブロックの1 辺の格子点数を N とすると、計算負荷と通信負荷は N3対 N2となるので N が大きいほど、相対的に通信負荷が減りフラット MPI 優位になると考えられる。403と 1603の比較ではその傾向が見られるが、803は異なる傾向となった。原因は不明である。64 ノードまでの計測を行ったが結果は 1 ノードと変わらなかった。た多ノードになるほどハイブリッド並列が優位になると想定されるが、この問題規模、H/W のバランス（CPU 演算速度と通信速度のバラン
ス）ではハイブリッド並列の優位は見られなかった。今後大規模ノードでの計測を試みる。
2.1.4.3

FX1、FX10、FX100、インテル CPU との比較

FX1(JSS)、FX10、FX100(SORA-MA)、インテル CPU(SORA-PP)の比較を行った結果を図 ５に示す。図 ５a) は H/W の性能差だけでなく後述する S/W チューニングを実施した効果を含
んだもの、図 ５b)は同じプログラムで H/W の差異（各 H/W で再コンパイルは実施した） を比較したものになる。S/W チューニングを含めると FX100 では FX1 の約 32 倍の性能が達成できた。この時 FX100 で標準的な 1CPU を 2 プロセス 16 スレッドで利用している。なお、
フラット MPI の方が速く、その場合は約 37 倍の性能が出せた。一方、同一プログラムの再コンパイルだけの比較では FX100 は FX1 に比べて約 11 倍となり、フラット MPI では約 16倍となった。理論ピーク性能では FX100 は FX1 の約 25 倍となるべきであるが、H/W の性能を活用するためにはチューニングが不可欠であることがわかる。

a) S/W チューニングを含む比較

b) H/W だけの比較

図 ５ FX1, FX10, FX100, インテル CPU との比較

4 / 253

2.1.5 高速化チューニング
FX100 向けにいくつかの高速化チューニングを実施した。詳細を表 2 に示す。
表 2

FX100 向け高速化チューニングの実施項目

版

実施項目

O

オリジナル（FX1 で利用）

A

flux 配列の構造体の変更＋SIMD 化促進

B

jk ループの融合（スレッド並列数の確保）

C

MFGS の書き下し＋OCL の挿入

Dflux 配列のインデックス変更（i,j,k,:）→（:,i,j,k）

E

flux 配列のインデックスの変更（C と D の比較で高速版を選択）
対流項：（i,j,k,:）
粘性項：（:,i,j,k）F

手動アンローリング
初期化のベクトル記述：dq=0 → OpenMP で並列化
保存量ループの展開（do n=1,nPhys を削除）

G

2 重ループの一重化をやめて OpenMP の collapse(2)を利用
データ通信の前後処理部の OpenMP 化
nPhys ループの位置の変更
MFGS（時間積分）で使われている Block Red-Black のブロック分割の最適化?t?={C,D,E,F,G}の cell 配列インデックスの変更（i,j,k,:）→（:,i,j,k）

これらの高速化チューニングは大きく分けるとa) 配列のインデックスの変更
b) データ構造（構造体）の変更
c) SIMD 化の促進に分けられる。a) の配列に関しては、プログラムの主要な配列としては有限体積法のセルで定義される cell 配列と、セル面の流束で定義される flux 配列がある。cell 配列はプログラムの中で大域的に使われる配列であるのに対し、flux 配列は対流項、粘性項の flux を計算する時だけに使われる配列である。これらの配列のインデックスが所謂ベクトル型（i,j,k,n）なのかスカラー型（n,i,j,k）が最適なのかを比較した。ここで、i,j,k が空間のインデックスを、n が物理量（乱流モデルなしの完全気体では 5 となる）を示す。b) の構造体に関しては flux 配列で使われるが、Structure of Array:SOA（配列の構造体）か Arrayof Structure:AOS（構造体の配列）のどちらが適切かを確認した。表 3 に具体例を示す。

5 / 253

表 3

データ構造（AOS、SOA）の例
O（AOS）

type cellFaceTypereal(8) :: areareal(8), dimension(5) :: flux
end typetype(cellFaceType), dimension(:,:,:), pointer :: cface
do n; do k; do j; do i
cface(i,j,k)%flux = …
enddo
A（SOA）
type cellFaceTypereal(8) :: areareal(8), dimension(:,:,:,:), pointer :: flux
end typetype(cellFaceType) :: cface
do n; do k; do j; do i
cface%flux(i,j,k,n) = …
enddoc) に関しては現状のコンパイラの最適化性能に依存する部分が大きいが、ソースを書き換えることで SIMD 化を促進する．この部分に関しては、今後コンパイラの成熟とともに書き換えが不要になることが期待される。
1) O から A
主に FX10 向けの高速化チューニングとして流束（対流項、粘性項）の計算部分に関して

flux 配列を AOS から SOA に変更



SIMD 化を促進するためにループ内の一時配列をスカラー化：a(3,3)を a_11, a_12, a_13,
a_21, a_22, a_23, a_31, a_32, a_33 に修正組み込み関数の手動展開を実施した。特に SIMD 化に関しては現状では最内ループに SIMD 化が適用されるため、ループボディに配列のベクトル表記があるとその部分が SIMD 化されてしまい他のループボデ
ィが SIMD 化されない状況となる。例えば

6 / 253

allocate(a(imax,5),b(imax,5),c(imax,5))
do i=1,imax
u = a(i,2)/a(i,1)
v= a(i,3)/a(i,1)
a(i,:) = b(i,:) + c(i,:)←ここだけ SIMD 化

enddoの場合、a(i,:) = ….の部分だけが SIMD 化されてしまい、残りの u = …, v = …，などがSIMD 化されない。この場合
allocate(a(imax,5),b(imax,5),c(imax,5))
do i=1,imax
u = a(i,2)/a(i,1)
v= a(i,3)/a(i,1)
a(i,1) = b(i,1) + c(i,1)
a(i,2) = b(i,2) + c(i,2)…
a(i,5) = b(i,5) + c(i,5)
enddoのように書き下してベクトル表記をなくすとループ内全てが SIMD 化される。
2) A から B
OpenMP によるスレッド並列は最外の k ループで実施するが、ループ長がスレッド数より短い場合はスレッド数が確保できないので手動で j,k ループを融合してループ長を稼いだ（二重ループの一重化）。
3) B から C
MFGS に関して


一時配列のスカラー化



OCL の挿入により依存関係を無視（計算は早くなるが収束性が悪化するため、トータル
でみた場合にどちらが良いかは未確認）を実施した。
4) C から D
flux 配列のインデックスを（i,j,k,:）から（:,i,j,k）へ変更した。

7 / 253

5) D から E
C と D を比較したところ対流項、粘性項のそれぞれで適したインデックスが異なることがわかった。そのためそれぞれに適したインデックスとして対流項は（i,j,k,:）、粘性項は（:,i,j,k）を採用した。この理由であるが、粘性項は速度の差分を多く計算するため、物理量（N=1～5、特に 2,3,4）の再利用性が高く、そのためスカラー型のインデックスが適している。一方対流項は物理量の再利用性が多くはないのでベクトル型のインデックスが適していると推測している。
6) E から F
flux 配列はローカルな配列で毎回初期化を行っており、その部分は自動並列に任せていたが、コンパイラが十分な最適化を実施できないことが判明したので OpenMP 化を実施した。
更に、3 次元空間の 3 重ループに追加して物理量のループ（n=1,nPhys、計 4 重ループ）がある部分に関して物理量ループをアンロールした。変更前は
do n=1,nPhys!$omp parallel do private(jk,i,j,k)do jk=1,jkmax
k = (jk-1)/jmax+1
j = jk-jmax*(k-1)
do i=1,imax
q(i,j,k,n) = …
…
enddo
enddo
!$omp end parallel do
enddoとなっており、この場合 OpenMP のオーバーヘッドが nPhys 分発生するなどのデメリットが考えられる。そのため!$omp parallel do private(jk,i,j,k)do jk=1,jkmax
k = (jk-1)/jmax+1
j = jk-jmax*(k-1)
do i=1,imax
q(i,j,k,1)= …

q(i,j,k,2) = …
…
enddo

8 / 253

enddo!$omp end parallel doとすることで n のループに対しても最適化が適用され性能の向上が期待できる。
7) F から G
B で行ったスレッド数確保のために j,k ループの手動融合を OpenMP の collapse を使う方式に変更した。ちなみに両方式で性能面での変化は見られなかった。MPI を使ったデータ通信部の前後処理部に関して自動並列が未対応な部分があり、その部分を OpenMP を用いたスレッド並列化を行った。F で実施した nPhys ループの書き下しは、汎用的なプログラムでは適用が難しいので nPhys ループの位置を変更することでベストではないがベターな性能を得ることができた。時間積分の MFGS（ガウスザイデル法の変形）をスレッド並列化する際に用いている Block Red-Black 法のブロック分割に関してパラメトリックスタディを行い、ブロック数の最適化を行った。図 ６に 1603の例を示す。理由は不明だがブロック数がスレッド数の 2 倍の時に最速となった。

図 ６ Block Red-Black のブロック分割による性能への影響
8) Ct, Dt, Et, Ft, Gt
高速化チューニングは主に flux 配列のインデックスに着目していたが、cell 配列のインデックスを（i,j,k,:）から（:,i,j,k）に変更したものを?t とした。これによりケースによっては cell 配列と flux 配列のインデックスが異なる場合もある。
図 ７にこれらの高速化チューニングの結果を示す。A の修正は SORA-MA にとっては高速化になっているが SORA-PP に対しては逆に遅くなっていることがわかる。SORA-MA もSORA-PP も同じスカラーCPU であるがチューニングによっては正反対の結果になる場合があることがわかった。また、ある高速化チューニングによってある部分は高速になるが、他

9 / 253

の部分は逆に遅くなるという事が発生することもわかった。
図 ８に示すように対流項と粘性項に関して比較を行うと、C から D で flux 配列のインデックスを変化させると、対流項は遅くなり、粘性項は速くなっていることがわかる。この結果を受けて E では対流項と粘性項の flux 配列のインデックスをそれぞれ最適なものとした。
この違いが発生した原因は前述したように、粘性項は速度の差分を多く計算するため物理量（N=1～5、特に 2,3,4）の再利用性が高くスカラー型のインデックスが適しているが、対流項は物理量の再利用性が多くはないのでベクトル型のインデックスが適していると推測している。

a) SORA-MA(FX100)b) SORA-PP(Intel CPU)

図 ７ 高速化チューニング結果（ブロックサイズは 1603）a) 対流項b) 粘性項図 ８ 対流項と粘性項の差

10 / 253

プログラム全体では時間積分（陰解法）、粘性項、対流項が大体 3 分割しており、その中でも viscous_cfacev（粘性流束の計算のため各種物理量の微分を計算する部分）、MFGS（時間積分）が比較的大きな割合を占めている。所謂ホットスポットが存在するようなプログ
ラムとは異なるため、高速化チューニングではより多くの部分を対象とする必要がある。
2.1.6 おわりにステンシル系アプリケーションによる FX100 の性能評価、高速化チューニングについて紹介した。本報告ではノード性能に注目して性能評価・高速化チューニングを実施したが、今後は更なる高速化とノード間での性能評価・高速化チューニングを実施する予定である。
A. STREAM の性能評価
STREAM は主にメモリ性能を測定するベンチマークプログラムである。STREAM では幾つかの演算種類があるが、ここでは一般的な TRIAD を用いた。TRIAD は
do i=1,Na(i) = b(i) + S * c(i)enddoとなる。a,b,c は 1 次元配列、S はスカラーである。図 A-1 に TRIAD の測定結果を示す。

図 A-1 TRIAD によるメモリ性能(SORA-MA, PP)
SORA-MA（FX100）、SORA-PP（図中では E5-2643V2 と表記）ともにノード内の全コアを使用している。SORA-MA、SORA-PP ともにループ長が 106付近（メモリ容量としては 24Mbyte 程度

11 / 253

で L2 キャッシュの容量程度）まではキャッシュによるアクセスであるが、それを超えるとキャッシュが溢れ、107 では完全なメモリアクセスになっていると考えられる。SORA-MA の場合、利用する配列（静的配列、ポインター、アロケータブル）によって性能が異なることがわかる。今後改善されることが期待されるが、現状では静的配列が 302GB/s で一番性能が高く、次にアロケータブル配列が 278GB/s、ポインターがかなり遅く 206GB/s となった
（現状では、contiguos 属性を設定することで性能が改善される）。なお、この結果を得る
ためにはラージページオプション（具体的には lpgparm –l demand）を指定する必要がある。
指定しないと動的配列（アロケータブル，ポインターともに）は 100GB/s 程度の性能となる。
図 A-2 に SORA-MA のスレッドスケーラビリティを示す。静的配列のケースで、ループ長
は 107で固定（キャッシュは溢れてメモリ性能を計測）してスレッドを 1 から 32 まで増やしたときのメモリ性能の変化を示している。図よりスレッドの増加に伴って特異な傾向を示していることがわかる。ここで，32 スレッド時のメモリ性能をコア数 32 で割った値が9.375 GB/s である。1 スレッドから 8 スレッドまではスレッドの増加にともない線形に性能が向上。8 スレッドから 16 スレッドまでは性能が頭打ちになっていることから。8 スレ
ッド以下では 1 コア当たり最大で 2 コア分のメモリ性能を使っていると推測できる。JSS の主計算機システムであった FX1 で同種の計測を行った場合、ノード内で 1 スレッド実行を行うと、そのスレッドはノードの全メモリ性能を占有できることがわかっており、それと似た状況である。16 スレッドを超えると再び線形（増加率は 1 コア当たりの性能である
9.375GB/s）に増加している。16 コアが 1CMG に所属しているため、16 スレッドを超えると別の CMG へのアクセスが発生する（いわゆる NUMA 構成）ためと考えられる。実際、numactl–interleave=all を使うことでほぼ線形な挙動を得ることができる。

12 / 253

図 A-2 TRIAD(ループ長は 107)のスレッドスケーラビリティ（SORA-MA）
参考文献
1) R.Takaki, K. Yamamoto, T. Yamane, S. Enomoto, and J. Mukai. The Development of
the UPACS CFD Environment. Vol. 2858 of Lecture Notes in Computer Science,
pp.307-319. Springer, 2003.

13 / 253

UPACSのFX10での性能評価
高木 亮治
宇宙航空研究開発機構

SS研ポストペタアプリ性能WG

1

性能評価概要▌ コード：圧縮性流体解析プログラムUPACS-L▌陰解法（Block Red-Black、2nd Euler、内部反復は2回）▌160x160x160の1ブロック（1プロセス計算）▌ 環境：▌FX10@東大▌オプション：-Kfast, parallel, openmp, swp, XFILL,
optmsg=2, noalias=s, array_private, preex,
dynamic_iteration -Qt -xSS研ポストペタアプリ性能WG

14 / 2532

流束データの階層構造
Original

Tune1（flux等の配列を変更）

type cellFaceTypereal(8) :: area,nt
real(8), dimension(3) :: nvreal(8), dimension(5) :: q_l,q_r
real(8), dimension(5) :: flux
end type

type cellFaceTypereal(8), pointer, dimension(:,:,:) :: area,nt
real(8),pointer, dimension(:,:,:,:) :: nvreal(8), pointer, dimension(:,:,:,:) :: q_l,q_r
real(8), pointer, dimension(:,:,:,:) :: flux
end type

type visCellFaceTypereal(8) :: area, mureal(8), dimension(3) :: nv, dTdx, ureal(8), dimension(5) :: flux
real(8), dimension(3,3) :: dudx
end typetype(*), pointer, dimension(:,:,:) :: cface

type visCellFaceTypereal(8), pointer, dimension(:,:,:) :: area, mureal(8), pointer, dimension(:,:,:,:) :: nv, dTdx, ureal(8), pointer, dimension(:,:,:,:) :: flux
real(8), pointer, dimension(:,:,:,:,:) :: dudx
end typetype(*) :: cface

do n ; do k ; do j ; do i
cface(i,j,k)%flux(n) …
enddo

do n ; do k ; do j ; do i
cface%flux(i,j,k,n) …
enddo
SS研ポストペタアプリ性能WG

3チューニング概要▌ original▌ tune1：構造体の変更▌tune1a：tune1 + 粘性項の修正▌一時配列のスカラー化：a(3,3) -> a_11,a_12,…
▌ SIMD化の促進（viscous_cfacev：0% → 99.19%）▌組み込み関数（matmul, dot_product）の手動展開▌ SIMD化の促進（viscous_flux：10.64% → 99.11%）▌tune1b:対流項はtune1、粘性項はoriginal

SS研ポストペタアプリ性能WG

15 / 2534計測結果（経過時間 [sec]）
ALL
alloc
pre
Convect
muscl
（対流項）
flux
post
alloc
pre
Viscouscfacev
（粘性項）
flux
post
MFGS（時間積分）

①
②

①

②a
②b
③a
②a

Tune1
623.0
5.791
0.4852
1.978
1.041
0.6837
5.335
1.720
27.80
564.5
0.68038.188③bTune1a50.20
5.763
0.48541.984
1.052
0.6832
5.331
1.720
18.01
1.314
0.67988.436

Tune1b
46.83
5.253
0.48532.034
1.037
0.68238.414
0.5929
9.007
1.482
4.422
8.243

alloc（配列のallocation）に時間がかかっている。
original→tune1で高速化
a.
b.

③

①

Original
58.00
6.760
0.4674
3.913
1.334
4.418
8.286
0.5870
8.741
1.482
4.421
11.98

対流項のmuscl, flux, post、粘性項のpost
粘性項のalloc（？）

original→tune1で低速化a.
b.

粘性項のpre, cfacev, flux（cfacevとfluxではSIMD化が減少）
tune1aでSIMD化を促進

SS研ポストペタアプリ性能WG

5original→tune1で高速化
convect-{muscl, flux, post}
viscous-post（viscous-alloc）
SS研ポストペタアプリ性能WG

16 / 2536

convect_muscl：
Original
3.913[s]Tune1
1.978[s]Tune1a1.984[s]浮動小数点演算ピーク比

6.4

12.7

12.6

メモリ/L2/L1ビジー率 [%]81/31/14

67/39/27

64/30/27

SIMD演算命令率 [%]

98.8

98.8

98.8

SIMDロード/ストア命令率 [%]5.1/3.7

0/0

0/0

L1Dミス率 [%]

11.3

4.6

4.6

43.8/56.2/0

40.3/60.0/0

40.7/59.3/0

8.96

3.37

3.37

L2ミスdm率/pf率 [%]24.4/75.6

15.3/84.7

15.3/84.7

ロード・ストア命令率 [%]

24.0

24.7

24.7

SIMD演算/演算命令率 [%]34.0/0.42

25.5/0.32

25.5/0.32

SIMD積和演算/積和演算命令率 [%]17.6/0.23

13.3/0.17

13.3/0.17

pf/分岐/その他命令率 [%]0/0.19/23.6

0/3.26/32.8

0/3.26/32.8

L1Dミスdm/hwpf/swpf率 [%]L2ミス率 [%]

7

SS研ポストペタアプリ性能WG

convect_flux：
Original
1.334[s]Tune11.041[s]Tune1a1.052[s]浮動小数点演算ピーク比

16.9

21.7

21.5

メモリ/L2/L1ビジー率 [%]90/26/14

65/40/20

63/35/19

SIMD演算命令率 [%]

99.2

99.2

99.2

SIMDロード/ストア命令率 [%]

0/0

0/0

0/0

L1Dミス率 [%]

6.34

6.53

6.72

46.5/53.5/0

26.1/73.9/0

26.4/73.6/0

6.36

6.02

6.02

L2ミスdm率/pf率 [%]4.52/95.5

19.6/80.4

19.5/80.5

ロード・ストア命令率 [%]

19.0

18.3

18.3

SIMD演算/演算命令率 [%]48.1/0.37

43.4/0.34

43.42/0.34

SIMD積和演算/積和演算命令率 [%]27.8/0.27

25.1/0.25

25.1/0.25

pf/分岐/その他命令率 [%]0/0.5/3.91

0/0.13/12.5

0/0.13/12.5

L1Dミスdm/hwpf/swpf率 [%]L2ミス率 [%]

SS研ポストペタアプリ性能WG

17 / 2538

convect_post：
Original
4.418[s]Tune10.6837[s]Tune1a0.6832[s]浮動小数点演算ピーク比

0.35

2.23

2.24

メモリ/L2/L1ビジー率 [%]73/52/11

86/50/30

86/50/30

SIMD演算命令率 [%]

98.8

98.8

98.8

SIMDロード/ストア命令率 [%]

0/0

0/0

0/0

L1Dミス率 [%]

33.6

4.23

4.23

90.6/9.38/0

1.13/98.9/0

1.13/98.9/0

31.8

4.11

4.11

L2ミスdm率/pf率 [%]57.6/42.4

7.86/92.1

7.84/92.2

ロード・ストア命令率 [%]

47.7

47.7

47.7

SIMD演算/演算命令率 [%]4.67/0.06

4.68/0.06

4.68/0.06

SIMD積和演算/積和演算命令率 [%]4.67/0.06

4.68/0.06

4.68/0.06

pf/分岐/その他命令率 [%]0/1.2/41.6

0/1.2/41.6

0/1.2/41.6

L1Dミスdm/hwpf/swpf率 [%]L2ミス率 [%]

9

SS研ポストペタアプリ性能WG{convect, viscous}_post
convect-post
original（4.418 [s]）tune1（0.6837 [s]）do n=1,bdtv_nFlowVar!$omp parallel do private(i,j,k,im,jm,km)
do k=1,blk%kn
do j=1,blk%jn
do i=1,blk%in
im = i-idelta(1) ; jm = j-idelta(2) ; km = k-idelta(3)blk%dq(i,j,k,n) = blk%dq(i,j,k,n) - blk%inv_vol(i,j,k) &* ( cface(i,j,k)%flux(n) - cface(im,jm,km)%flux(n) )end do ; enddo ; enddo!$omp end parallel doend dodo n=1,bdtv_nFlowVar!$omp parallel do private(i,j,im,jm,km)
do k=1,blk%kn
do j=1,blk%jn
do i=1,blk%in
im = i-idelta(1) ; jm = j-idelta(2) ; km = k-idelta(3)blk%dq(i,j,k,n) = blk%dq(i,j,k,n) - blk%inv_vol(i,j,k) &* ( cface%flux(i,j,k,n) - cface%flux(im,jm,km,n) )end do ; enddo ; enddo!$omp end parallel doend doviscous-post
original（4.421 [s]）tune1（0.6803 [s]）do n=1,bdtv_nFlowVar!$omp parallel do private(i,j,k,im,jm,km)
do k=1,blk%kn
do j=1,blk%jn
do i=1,blk%in
im = i -idelta(1) ; jm = j -idelta(2) ; km = k -idelta(3)blk%dq(i,j,k,n) = blk%dq(i,j,k,n) - blk%inv_vol(i,j,k) &* ( cface(i,j,k)%flux(n) - cface(im,jm,km)%flux(n) )end do ; enddo ; enddo!$omp end parallel doend dodo n=1,bdtv_nFlowVar!$omp parallel do private(i,j,k,im,jm,km)
do k=1,blk%kn
do j=1,blk%jn
do i=1,blk%in
im = i -idelta(1) ; jm = j -idelta(2) ; km = k -idelta(3)blk%dq(i,j,k,n) = blk%dq(i,j,k,n) - blk%inv_vol(i,j,k) &* ( cface%flux(i,j,k,n) - cface%flux(im,jm,km,n) )end do ; enddo ; enddo!$omp end parallel doend doSS研ポストペタアプリ性能WG

18 / 25310

original→tune1で低速化
viscous-{pre,cfacev, flux}
tune1のチューニング（tune1a）

11

SS研ポストペタアプリ性能WG

viscous_preoriginal（0.5870 [s]）tune1（1.720 [s]）cface%dudx = 0.0
cface%dTdx = 0.0 ; cface%u = 0.0
cface%area = 0.0 ; cface%nv = 0.0
cface%mu = 0.0 ; cface%flux = 0.0!$omp parallel do private(i,j,k)
do k=-1,blk%kn
do j=-1,blk%jn
do i=-1,blk%in
cface(i,j,k)%dudx(:,:) = 0.0
cface(i,j,k)%dTdx(:) = 0.0 ; cface(i,j,k)%u(:) = 0.0
cface(i,j,k)%area= 0.0 ; cface(i,j,k)%nv(:) = 0.0
cface(i,j,k)%mu= 0.0 ; cface(i,j,k)%flux(:) = 0.0
end do ; end do ; end do!$omp end parallel dooriginal

tune1

tune1aメモリ/L2/L1ビジー率 [%]93/40/21

27/12/31

27/12/31

SIMDロード/ストア命令率 [%]0/31.6

0/24.80/24.8

L1Dミス率 [%]

6.25

6.04

6.04

21.6/4.11/74.3

65.9/23.0/11.1

65.9/23.0/11.1

6.25

3.99

3.99

L2ミスdm率/pf率 [%]4.39/95.6

19.6/80.4

19.7/80.4

ロード・ストア命令率 [%]

9.82

23.5

23.5

pf/分岐/その他命令率 [%]1.55/14.2/74.4

0.7/18.9/56.9

0.7/18.9/56.9

L1Dミスdm/hwpf/swpf率 [%]L2ミス率 [%]

SS研ポストペタアプリ性能WG

19 / 25312

viscous_preOriginal（0.5870 [s]）
31
32
33
34

1 p
2 p
3 p

35

3 p

36

3 p

37

3 p

38
39
40
41
42

3
3
2
1

p
p
p
p

Tune1（1.720 [s]）!$omp parallel do private(i,j,k)
do k=-1,blk%kn
do j=-1,blk%jn
do i=-1,blk%in<<< Loop-information Start >>><<< [OPTIMIZATION]<<< SIMD<<< PREFETCH:2<<<
cface: 2<<< Loop-information End >>>v
cface(i,j,k)%dudx(:,:) = 0.0<<< Loop-information Start >>><<< [OPTIMIZATION]<<< FULL UNROLLING<<< Loop-information End >>>fcface(i,j,k)%dTdx(:) = 0.0 ; …
<<< Loop-information Start >>><<< [OPTIMIZATION]<<< SIMD<<< Loop-information End >>>mcface(i,j,k)%area= 0.0 ; …
<<< Loop-information Start >>><<< [OPTIMIZATION]<<< SIMD<<< Loop-information End >>>mcface(i,j,k)%mu= 0.0 ; …
end doend doend do!$omp end parallel do<<< Loop-information Start >>><<< [PARALLELIZATION]<<< Standard iteration count: 2<<< [OPTIMIZATION]<<< SIMD<<< OTHER PREFETCH : 1<<< OTHER XFILL : 1<<< Loop-information End >>>37
pp v
cface%dudx = 0.0<<< Loop-information Start >>><<< [PARALLELIZATION]<<< Standard iteration count: 2<<< [OPTIMIZATION]<<< SIMD<<< OTHER PREFETCH : 2<<< OTHER XFILL : 2<<< Loop-information End >>>38
pp v
cface%dTdx = 0.0 ; cface%u = 0.0<<< Loop-information Start >>><<< [PARALLELIZATION]<<< Standard iteration count: 2<<< [OPTIMIZATION]<<< SIMD<<< OTHER PREFETCH : 4<<< OTHER XFILL : 4<<< Loop-information End >>>39
pp v
cface%area = 0.0 ; cface%nv = 0.0<<< Loop-information Start >>><<< [PARALLELIZATION]<<< Standard iteration count: 2<<< [OPTIMIZATION]<<< SIMD<<< OTHER PREFETCH : 4<<< OTHER XFILL : 4
SS研ポストペタアプリ性能WG<<< Loop-information End >>>40
pp v
cface%mu = 0.0 ; cface%flux = 0.013convect_preconvect-preoriginal（0.4674 [s]）tune1（0.4852 [s]）!$omp parallel do private(i,j,k)
do k=1,blk%kn
do j=1,blk%jn
do i=1,blk%in
cface(i,j,k)%area = 0.0
cface(i,j,k)%nt = 0.0
cface(i,j,k)%nv(:) = 0.0
cface(i,j,k)%q_l(:) = 0.0
cface(i,j,k)%q_r(:) = 0.0
cface(i,j,k)%flux(:) = 0.0
enddo ; enddo ; enddo!$omp end parallel docface%area = 0.0
cface%nt = 0.0
cface%nv = 0.0
cface%q_l = 0.0
cface%q_r = 0.0
cface%flux = 0.0

viscous-preoriginal（0.5870 [s]）tune1（1.720 [s]）!$omp parallel do private(i,j,k)
do k=-1,blk%kn
do j=-1,blk%jn
do i=-1,blk%in
cface(i,j,k)%dudx(:,:) = 0.0
cface(i,j,k)%dTdx(:) = 0.0 ; cface(i,j,k)%u(:) = 0.0
cface(i,j,k)%area= 0.0 ; cface(i,j,k)%nv(:) = 0.0
cface(i,j,k)%mu= 0.0 ; cface(i,j,k)%flux(:) = 0.0
end do ; enddo ; enddo!$omp end parallel docface%dudx = 0.0
cface%dTdx = 0.0 ; cface%u = 0.0
cface%area = 0.0 ; cface%nv = 0.0
cface%mu = 0.0 ; cface%flux = 0.0※doループを使って明示的に書き下しても性能は変わらず

SS研ポストペタアプリ性能WG

20 / 25314

viscous_cfacev：変数のスカラー化
Tune1（27.8 [s]）Tune1a（18.01 [s]）!$omp parallel do private(i,j,k,…)do k = isrt(3),iend(3)do j = isrt(2),iend(2)do i = isrt(1),iend(1)!$omp parallel do private(i,j,k,….)do k = isrt(3),iend(3)do j = isrt(2),iend(2)do i = isrt(1),iend(1)i1 = i + idelta(1) ; j1 = j + idelta(2) ; k1 = k + idelta(3)i1 = i + idelta(1) ; j1 = j + idelta(2) ; k1 = k + idelta(3)!

!

xi derivative

u0_1 = blk%q(i ,j ,k ,2) / blk%q(i ,j ,k ,1)
u0_2 = blk%q(i ,j ,k ,3) / blk%q(i ,j ,k ,1)
u0_3 = blk%q(i ,j ,k ,4) / blk%q(i ,j ,k ,1)
u1_1 = blk%q(i1,j1,k1,2) / blk%q(i1,j1,k1,1)
u1_2 = blk%q(i1,j1,k1,3) / blk%q(i1,j1,k1,1)
u1_3 = blk%q(i1,j1,k1,4) / blk%q(i1,j1,k1,1)

u_0(1:3) = blk%q(i ,j ,k ,2:4) / blk%q(i ,j ,k ,1)
u_1(1:3) = blk%q(i1,j1,k1,2:4) / blk%q(i1,j1,k1,1)
T_0
T_1

xi derivative= GAMMA * blk%p(i ,j ,k ) / blk%q(i ,j ,k ,1)= GAMMA * blk%p(i1,j1,k1) / blk%q(i1,j1,k1,1)

T_0
T_1

dudx1(1,:) = blk%xix(i ,j ,k ,ixi,:) * ( u_1(1) - u_0(1) )dudx1(2,:) = blk%xix(i ,j ,k ,ixi,:) * ( u_1(2) - u_0(2) )dudx1(3,:) = blk%xix(i ,j ,k ,ixi,:) * ( u_1(3) - u_0(3) )dTdx1( :) = blk%xix(i ,j ,k ,ixi,:) * ( T_1 - T_0 )= GAMMA * blk%p(i ,j ,k ) / blk%q(i ,j ,k ,1)= GAMMA * blk%p(i1,j1,k1) / blk%q(i1,j1,k1,1)

dudx1_11 = blk%xix(i ,j ,k ,ixi,1) * ( u1_1 - u0_1 )dudx1_12 = blk%xix(i ,j ,k ,ixi,2) * ( u1_1 - u0_1 )dudx1_13 = blk%xix(i ,j ,k ,ixi,3) * ( u1_1 - u0_1 )dudx1_21 = blk%xix(i ,j ,k ,ixi,1) * ( u1_2 - u0_2 )dudx1_22 = blk%xix(i ,j ,k ,ixi,2) * ( u1_2 - u0_2 )dudx1_23 = blk%xix(i ,j ,k ,ixi,3) * ( u1_2 - u0_2 )dudx1_31 = blk%xix(i ,j ,k ,ixi,1) * ( u1_3 - u0_3 )dudx1_32 = blk%xix(i ,j ,k ,ixi,2) * ( u1_3 - u0_3 )dudx1_33 = blk%xix(i ,j ,k ,ixi,3) * ( u1_3 - u0_3 )dTdx1_1 = blk%xix(i ,j ,k ,ixi,1) * ( T_1 - T_0 )dTdx1_2 = blk%xix(i ,j ,k ,ixi,2) * ( T_1 - T_0 )dTdx1_3 = blk%xix(i ,j ,k ,ixi,3) * ( T_1 - T_0 )…

15

SS研ポストペタアプリ性能WG

viscous_cfacev：変数のスカラー化
Tune1（27.8 [s]）121 !$omp parallel do private(i,j,k,…)122
123 1 pdo k = isrt(3),iend(3)
124 2 pdo j = isrt(2),iend(2)
125 3 pdo i = isrt(1),iend(1)
126 3
127 3 pi1 = i + idelta(1) ; …
128 3
129 3
! xi derivative
130 3<<< Loop-information Start >>><<< [OPTIMIZATION]<<< FULL UNROLLING<<< Loop-information End >>>131 3 p fu_0(1:3) = …
132 3 p f
u_1(1:3) = …
133 3
134 3 pT_0=…
135 3 p
T_1
=…
136 3
<<< Loop-information Start >>><<< [OPTIMIZATION]<<< FULL UNROLLING<<< Loop-information End >>>137 3 p f
dudx1(1,:) = …
138 3 p f
dudx1(2,:) = …
139 3 p f
dudx1(3,:) = …
140 3 p f
dTdx1( :) = …

Tune1a（18.01 [s]）139 !$omp parallel do private(i,j,k,…)148 1 pdo k = isrt(3),iend(3)
149 2 pdo j = isrt(2),iend(2)<<< Loop-information Start >>><<< [OPTIMIZATION]<<< SIMD<<< Loop-information End >>>150 3 p v
do i = isrt(1),iend(1)
151 3
152 3 p v
i1 = i + idelta(1) ; …
153 3
154 3
! xi derivative
155 3
158 3 p v
u0_1 = …
159 3 p v
u0_2 = …
160 3 p v
u0_3 = …
161 3 p v
u1_1 = …
162 3 p v
u1_2 = …
163 3 p v
u1_3 = …
164 3
165 3 p v
T_0=…
166 3 p v
T_1
=…
167 3
172 3 p v
dudx1_11 = …
173 3 p v
dudx1_12 = …
174 3 p v
dudx1_13 = …
175 3 p v
dudx1_21 = …
176 3 p v
dudx1_22 = …
177 3 p v
dudx1_23 = …
178 3 p v
dudx1_31 = …
179 3 p v
dudx1_32 = …
180 3 p v
dudx1_33 = …
181 3 p v
dTdx1_1 = …
182 3 p v
dTdx1_2 = …
SS研ポストペタアプリ性能WG
183 3 p v
dTdx1_3 = …

21 / 25316

viscous_cfacev：
Original
8.741[s]Tune127.80[s]Tune1a18.01[s]浮動小数点演算ピーク比

6.81

2.19

2.93

メモリ/L2/L1ビジー率 [%]27/19/33

7/11/16

11/13/12

SIMD演算命令率 [%]

99.1

0

99.2

SIMDロード/ストア命令率 [%]

0/0

0/0

0/0

L1Dミス率 [%]

1.97

3.94

6.97

78.4/21.6/0

99.9/0.13/0

99.9/0.14/0

1.01

0.68

1.66

L2ミスdm率/pf率 [%]53.9/47.1

91.3/8.75

91.2/8.78

ロード・ストア命令率 [%]

48.7

39.1

36.8

SIMD演算/演算命令率 [%]8.6/0.11

0/12.3

10.1/0.11

SIMD積和演算/積和演算命令率 [%]14.9/0.11

0/16.915.9/0.11

pf/分岐/その他命令率 [%]0/0.13/27.5

0/3.62/28.0

0/4.26/32.8

L1Dミスdm/hwpf/swpf率 [%]L2ミス率 [%]

SS研ポストペタアプリ性能WG

17viscous_flux：組み込み関数の手動展開
Tune1（564.5[s]）Tune1a（1.314[s]）!$omp parallel do private(i,j,k,div_u,tau)
do k = isrt(3),iend(3)do j = isrt(2),iend(2)do i = isrt(1),iend(1)!$omp parallel do private(i,j,k,div_u,tau)
do k = isrt(3),iend(3)do j = isrt(2),iend(2)do i = isrt(1),iend(1)

[途中略]

[途中略]

f%flux(i,j,k,1) = 0.
f%flux(i,j,k,2:4) = f%mu(i,j,k) * matmul(tau(:,:), f%nv(i,j,k,:))f%flux(i,j,k,5) = dot_product(f%flux(i,j,k,2:4),f%u(i,j,k,1:3)) &+ dot_product(f%dTdx(i,j,k,:) ,f%nv(i,j,k,:) ) &* f%mu(i,j,k)/PRANDTL/GAMMA_1
f%flux(i,j,k,:) = -f%area(i,j,k) * f%flux(i,j,k,:)end doend doend dof%flux(i,j,k,1) = 0.
f%flux(i,j,k,2) = f%mu(i,j,k) &* (tau(1,1)*f%nv(i,j,k,1)+tau(1,2)*f%nv(i,j,k,2)+tau(1,3)*f%nv(i,j,k,3))
f%flux(i,j,k,3) = f%mu(i,j,k) &* (tau(2,1)*f%nv(i,j,k,1)+tau(2,2)*f%nv(i,j,k,2)+tau(2,3)*f%nv(i,j,k,3))
f%flux(i,j,k,4) = f%mu(i,j,k) &* (tau(3,1)*f%nv(i,j,k,1)+tau(3,2)*f%nv(i,j,k,2)+tau(3,3)*f%nv(i,j,k,3))
f%flux(i,j,k,5) = f%flux(i,j,k,2)*f%u(i,j,k,1) &+ f%flux(i,j,k,3)*f%u(i,j,k,2) + f%flux(i,j,k,4)*f%u(i,j,k,3) &+ f%mu(i,j,k)/PRANDTL/GAMMA_1 &* ( f%dTdx(i,j,k,1)*f%nv(i,j,k,1)+f%dTdx(i,j,k,2)*f%nv(i,j,k,2) &+ f%dTdx(i,j,k,3)*f%nv(i,j,k,3) )f%flux(i,j,k,1) = -f%area(i,j,k) * f%flux(i,j,k,1)
f%flux(i,j,k,2) = -f%area(i,j,k) * f%flux(i,j,k,2)
f%flux(i,j,k,3) = -f%area(i,j,k) * f%flux(i,j,k,3)
f%flux(i,j,k,4) = -f%area(i,j,k) * f%flux(i,j,k,4)
f%flux(i,j,k,5) = -f%area(i,j,k) * f%flux(i,j,k,5)
end doend doend doSS研ポストペタアプリ性能WG

22 / 25318

viscous_flux：組み込み関数の手動展開
Tune1（564.5[s]）Tune1a（1.314[s]）259!$omp parallel do
private(i,j,k,div_u,tau)
260 1 pdo k = isrt(3),iend(3)261 2 pdo j = isrt(2),iend(2)262 3 pdo i = isrt(1),iend(1)

442
443
444

1 p
2 p

445

3 p

[途中略]
277

279

f%flux(i,j,k,1) = …
<<< Loop-information Start >>><<< [OPTIMIZATION]<<< FULL UNROLLING<<< Loop-information End >>>3 p f
f%flux(i,j,k,2:4) = …
<<< Loop-information Start >>><<< [OPTIMIZATION]<<< SIMD<<< SOFTWARE PIPELINING<<< Loop-information End >>>3 p 6v
f%flux(i,j,k,5) = …

283
284
285
286
287

<<< Loop-information Start >>><<< [OPTIMIZATION]<<< SIMD<<< Loop-information End >>>p v
end do3 p 6v
f%flux(i,j,k,:) = …
p
end do33 p
end dop
end doSS研ポストペタアプリ性能WG
2 p
end do1 p
end do278

3 p!$omp parallel do private(i,j,k,div_u,tau)
do k = isrt(3),iend(3)do j = isrt(2),iend(2)<<< Loop-information Start >>><<< [OPTIMIZATION]<<< SIMD<<< SOFTWARE PIPELINING<<< Loop-information End >>>v
do i = isrt(1),iend(1)

[途中略]
459
460
461
463
465
467

3
3
3
3
3
3

481
482
483
484
485
486
487
488
489

3
3
3
3
3
3
3
2
1

p
p
p
p
p

v
v
v
v
v

f%flux(i,j,k,1) = 0.
f%flux(i,j,k,2) = …
f%flux(i,j,k,3) = …
f%flux(i,j,k,4) = …
f%flux(i,j,k,5) = …

p
p
p
p
p

v
v
v
v
v

f%flux(i,j,k,1) = -f%area(i,j,k) * f%flux(i,j,k,1)
f%flux(i,j,k,2) = -f%area(i,j,k) * f%flux(i,j,k,2)
f%flux(i,j,k,3) = -f%area(i,j,k) * f%flux(i,j,k,3)
f%flux(i,j,k,4) = -f%area(i,j,k) * f%flux(i,j,k,4)
f%flux(i,j,k,5) = -f%area(i,j,k) * f%flux(i,j,k,5)

19

viscous_flux：
Original
1.482[s]Tune1564.5[s]Tune1a1.314[s]浮動小数点演算ピーク比

3.81

0.01

4.21

メモリ/L2/L1ビジー率 [%]93/43/21

0/3/7

60/38/18

SIMD演算命令率 [%]

99.1

10.6

99.1

SIMDロード/ストア命令率 [%]

0/0

0/0

0/0

L1Dミス率 [%]

4.45

2.41

6.49

49.3/50.7/097.2/1.71/1.07

44.0/56.0/0

4.46

0.03

5.96

L2ミスdm率/pf率 [%]16.0/84.1

92.2/7.83

35.2/64.8

ロード・ストア命令率 [%]

61.5

26.3

49.4

SIMD演算/演算命令率 [%]19.9/0.19

0.02/0.10

20.2/0.21

SIMD積和演算/積和演算命令率 [%]13.8/0.10

0/0.0914.7/0.11

pf/分岐/その他命令率 [%]0/0.92/3.65

0.04/22.7/50.8

0/0.53/14.9

L1Dミスdm/hwpf/swpf率 [%]L2ミス率 [%]

SS研ポストペタアプリ性能WG

23 / 253

20

その他
PAツールの挙動不審
スレッドスケーリング{convect, viscous}_postの補足
21

SS研ポストペタアプリ性能WG

PAを取ると性能が変化する
tune1

tune1(PA)tune1btune1b(PA)

634.4

627.8

51.24

46.27

alloc

5.999

6.128

6.121

5.241

pre

0.48540.4852

0.48790.4882

muscl_flux

3.041

3.545

3.584

3.040

post

0.68340.67780.67810.6842

alloc

5.539

6.894

8.240

8.397

pre

1.720

1.719

0.5846

0.5863

cfacev_flux

596.5

596.7

9.650

10.14

post

0.67930.6741

4.425

4.421

11.82

8.452

11.79

8.086

ALL

Convect

Viscous

MFGS

古いversionのデータ。最新versionでも一部発生
SS研ポストペタアプリ性能WG

24 / 25322スレッド並列性能（強スケーリング）
80x80x80
スレッド数
計算時間 [sec]速度比
効率 [%]
160x160x160
スレッド数
計算時間 [sec]速度比
効率 [%]
320x320x320
スレッド数
計算時間 [sec]速度比
効率 [%]

1
38.05
1
-

2
20.21
1.88
94.1

4
10.90
3.49
87.3

8
6.268
6.07
75.9

16
4.113
9.25
57.8

1
364.4
1
-

2
190.1
1.917
95.8

4
107.7
3.383
84.6

8
69.40
5.251
65.6

16
57.78
6.307
39.4

1
3413
1
-

2
1878
1.817
90.9

4
1113
3.066
76.7

8
676.1
5.048
63.1

16
533.0
6.403
40.0

SS研ポストペタアプリ性能WG

23{convect, viscosu}_postのカーネル評価▌ カーネル化▌ データ：3D構造格子上で定義される物理量▌ 保存量：dq、流束：flux▌ 計算式：保存量と流束の関係（ステンシル計算）▌ dq(i,j,k,n) = dq(i,j,k,n)+S(i,j,k)*(flux(i,j,k,n)-flux(i-1,j,k,n))▌ dq(i,j,k,n) = dq(i,j,k,n)+S(i,j,k)*(flux(i,j,k,n)-flux(i,j-1,k,n))▌ dq(i,j,k,n) = dq(i,j,k,n)+S(i,j,k)*(flux(i,j,k,n)-flux(i,j,k-1,n))▌ 性能の確認▌ データ構造（dq,flux）▌ a(i,j,k)%d(n) vs a%d(i,j,k,n), (i,j,k,n) vs (n,i,j,k)▌ i,j,k：ブロックサイズ、n:物理変数（～5）▌ ループ構造▌ ループの順番、ベクトル表記
SS研ポストペタアプリ性能WG

25 / 25324

a(i,j,k)%d(n) do-kjin!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
do n=1,nmax
im = i-idelta(1,dir)dq(i,j,k)%d(n) = dq(i,j,k)%d(n) + S(i,j,k)*(flux(i,j,k)%d(n)-flux(im,jm,km)%d(n))
enddo
enddo ; enddo ; enddo!$omp end parallel do△a(i,j,k)%d(n) do-nkji
do n=1,nmax!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
im = i-idelta(1,dir)dq(i,j,k)%d(n) = dq(i,j,k)%d(n) + S(i,j,k)*(flux(i,j,k)%d(n)-flux(im,jm,km)%d(n))
enddo ; enddo ; enddo!$omp end parallel do
enddo

×

a(i,j,k)%d(n) do-kji:!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
im = i-idelta(1,dir)dq(i,j,k)%d(:) = dq(i,j,k)%d(:) + S(i,j,k)*(flux(i,j,k)%d(:)-flux(im,jm,km)%d(:))
enddo ; enddo ; enddo!$omp end parallel do△25

SS研ポストペタアプリ性能WG

a%d(i,j,k,n) do‐nkji
do n=1,nmax!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
im = i‐idelta(1,dir)
dq%d(i,j,k,n) = dq%d(i,j,k,n) + S(i,j,k)*(flux%d(i,j,k,n)‐flux%d(im,jm,km,n))
enddo ; enddo ; enddo!$omp end parallel do
edndo

○

a%d(i,j,k,n) do‐kji;!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
im = i‐idelta(1,dir)
dq%d(i,j,k,:) = dq%d(i,j,k,:) + S(i,j,k)*(flux%d(i,j,k,:)‐flux%d(im,jm,km,:))enddo ; enddo ; enddo!$omp end parallel do○a%d(i,j,k,n) do‐kjin!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
do n=1,nmax
im = i‐idelta(1,dir)
dq%d(i,j,k,n) = dq%d(i,j,k,n) + S(i,j,k)*(flux%d(i,j,k,n)‐flux%d(im,jm,km,n))edond
enddo ; enddo ; enddo!$omp end parallel doSS研ポストペタアプリ性能WG

26 / 253○26

a%d(n,i,j,k) do‐nkji
do n=1,nmax!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
im = i‐idelta(1,dir)
dq%d(n,i,j,k) = dq%d(n,i,j,k) + S(i,j,k)*(flux%d(n,i,j,k)‐flux%d(n,im,jm,km))
enddo ; enddo ; enddo!$omp end parallel do
edndo

△

a%d(n,i,j,k) do‐kji;!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
im = i‐idelta(1,dir)
dq%d(:,i,j,k) = dq%d(:,i,j,k) + S(i,j,k)*(flux%d(:,i,j,k)‐flux%d(:,im,jm,km))
enddo ; enddo ; enddo!$omp end parallel do○a%d(n,i,j,k) do‐kjin!$omp parallel dodo k=1,kmax ; do j=1,jmax ; do i=1,imax
do n=1,nmax
im = i‐idelta(1,dir)
dq%d(n,i,j,k) = dq%d(n,i,j,k) + S(i,j,k)*(flux%d(n,i,j,k)‐flux%d(n,im,jm,km))
edond
enddo ; enddo ; enddo!$omp end parallel doSS研ポストペタアプリ性能WG

▌
▌
▌

○

27

a(i,j,k)%d(n) よりも a%d(i,j,k,n) が高速。
a%d(i,j,k,n) と a%d(n,i,j,k) はほとんど差がない。
a%d(i,j,k,n) と a%d(i,j,k,:) もほとんど差がない。
SS研ポストペタアプリ性能WG

27 / 253

28

まとめ▌ UPACS-LをFX10上で（ちょこっと）チューニングを行った。
▌流束のデータ構造を変更。
▌ソースの書き換えでSIMD化を促進。

▌ ステンシル計算（更新ベクトルの計算）の基礎的なデータを取得した。
▌データ構造：インデックスの順番▌ループ構造：ループの順番、ベクトル表記など
SS研ポストペタアプリ性能WG

28 / 25329

2.2 ハイブリッド非構造格子 CFD ソルバのメモリ階層構造への対応および有限体積法における再帰参照と SIMD 化
宇宙航空研究開発機構
坂下雅秀

ポストペタアプリ WG の会合で報告した内容の概要について、以下に示す。
第四回会合（2014 年 12 月 10 日）では、「ハイブリッド非構造格子 CFD ソルバのメモリ
階層構造への対応」と題して、CFD ソルバにおける固有の問題点と、キャッシュメモリへの対応方法についてまとめた。キャッシュの有効利用とは、キャッシュに乗せたデータでいかに多くの計算を行うかに尽きるが、CFD ソルバの採用する、いわゆるステンシル系の計算では、そもそもデータの再利用回数が少ないため、なかなか効率の良い方法が存在しないのが現状であり、前途多難である。
第七回会合（2015 年 10 月 8 日）では、「有限体積法における再帰参照と SIMD 化」と題して、多くの CFD ソルバが採用する有限体積法において SIMD 化に際して問題となる再帰
参照と、その対処方法についてまとめた。また、実機（FX100）が利用可能となったため、非構造格子 CFD ソルバにおけて、実際に FX100 を使用した SIMD 化チューニングの一例
について報告した。この例では、当該ソルバがサポートするいくつかの機能を諦めることによって SIMD 化の促進を図り、SIMD 化前に比べて計算時間で 1.5 倍、理論ピーク性能
比では 6.3%という期待以上の性能が得られた。
一般に、実用に供するアプリは多数のユーザの多様な要求に答えるため、多くの機能を実装する必要に迫られる運命にある。このため、SIMD 化したい主要な DO ループが SIMD
化の障害となりうる複雑な構造を持たざるを得なくなることが多い。そこで、特定ユーザを念頭に、思い切って機能を絞り込み、主要な DO ループを簡素化することによって SIMD化を促進し性能向上を図ることは、有力な選択肢のひとつである。
一方で、単純な DO ループしか SIMD 化できず性能の出ない SIMD アーキテクチャのシ
ステムでは実用的とはいえない。そこで、いっさいの機能を諦めることなく、FX100 でど
こまで SIMD 化し性能を出せるかについても重要なテーマであるといえる。

29 / 253

ハイブリッド非構造格子CFDソルバのメモリ階層構造への対応

宇宙航空研究開発機構
坂下雅秀

1

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

非構造格子CFDソルバにおける問題点• 主要ループはすべてランダムアクセス
FACOM230-75 APUの時代から性能が出ない
とりあえず、キャッシュ（オンチップメモリ）にのせてreordering
メモリ階層構造への対応
やらなければいけないことはPhiでもGPUでも
SX-ACEでもあまり変わらない• 時間積分に陰解法が使われることが多い
並列化が困難陽解法にしてしまうという方法はある
Krylov部分空間法を使うことにして前処理は？
2

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
30 / 253

キャッシュに「のっていない」状態••••

データ xが 計算に必要となるメモリ（オフチップメモリ）→キャッシュ→レジスタ
データ yが 計算に必要となる
メモリ→キャッシュ→レジスタ：• キャッシュがいっぱいになりデータxが追い出される：• 再びデータ xが 計算に必要となる• メモリ→キャッシュ→レジスタ

メモリ―キャッシュ間の転送回数が多い状態
3

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

キャッシュに「のっている」状態
データ xが 計算に必要となる
メモリ→キャッシュ→レジスタ
データ yが 計算に必要となる
メモリ→キャッシュ→レジスタ：• 再びデータ xが 計算に必要となる• xがキャッシュに残っている••••

メモリ―キャッシュ間の転送回数が少ない状態
4

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
31 / 253• 要するにキャッシュに「のっていない」 「のっている」とは転送回数が「多い」「少ない」ということ• 当該データが１回しか使われないなら意味がない

5

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

回数で考えるメリット• 直観的でわかりやすい
PAで出してくれたらいいな

6

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
32 / 253回数の計算方法• スループットを使うと，データ転送がオー
バーラップして隠れている部分は回数にカウントされない• キャッシュミス回数を使うと実際に転送されている回数が計算される
隠れているのならカウントされなくていい？
7

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

回数の計算• L1⇔L2キャッシュ間データ転送量[byte]（PA）
L1$⇔L2$間スループット[GB/s]×浮動小数点L2$ヒット[s]• L2キャッシュ⇔メモリ間データ転送量[byte]（PA）メモリスループット[GB/s]×浮動小数点L2$ミス[s]• 定義・参照データサイズ
定義・参照データ（配列）のサイズ[byte]
直観的な指標なのでどんぶり勘定でOK

回数＝データ転送量÷定義・参照データサイズ
8

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
33 / 253

例題：行列・行列積の計算C=AB
implicit NONE
integer, parameter :: N= 4096
!行列のサイズ
real*8,allocatable :: A(:,:), B(:,:), C(:,:)
integer :: i, j, k
allocate(A(N,N),B(N,N),C(N,N))(snip)
do j=1,N
do k=1,N
do i=1,NC(i,j) = C(i,j) + A(i,k)*B(k,j)
end doend doend do(snip)
9

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

PA測定結果時間 (sec)

時間 (sec)
1.5E+02

3.0E-02

1.0E+022.0E-02

5.0E+01

1.0E-02

0.0E+00

0.0E+00

Process 0

Process 0

行列・行列積の計算N=4096

平均の計算 C(i)=0.5*(A(i)+B(i)), i=1, 107

L1$⇔L2$間転送回数≒65=4.08×109×69.0÷(8×32×40962)
L2$⇔メモリ間転送回数≒0.2=4.05×109×0.20÷(8×32×40962)
10

L1$⇔L2$間転送回数≒0.6=8.61×109×0.016÷(8×3×107)
L2$⇔メモリ間転送回数≒0.2=11.57×109×6.62×10‐4÷(8×3×107)
SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
34 / 253• 回数が多く性能に不満がある
タイリング（＋アクセスの連続化）
etc.

• 回数が少なく性能に不満がある
データの再利用が図れるようなループの融合
etc.
あとは

具体的な事例集があればなんとかなる？
11

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

行列・行列積のタイリング
implicit NONE
integer, parameter :: NN = 4096 ! 行列のサイズ
integer, parameter :: NT = 256 ! タイル（小行列）の数
integer, parameter :: NB = NN/NT ! タイル（小行列）のサイズ
real*8,allocatable :: A(:,:,:,:), B(:,:,:,:), C(:,:,:,:)
integer :: i , j , k , l, m, nallocate( A(NB,NB,NT,NT), B(NB,NB,NT,NT), C(NB,NB,NT,NT) )(snip)
do n=1,NT; do m=1,NT; do l=1,NT
do j=1,NB
do k=1,NB
do i=1,NB
C(i,j,l,n) = C(i,j,l,n) + A(i,k,l,m)*B(k,j,m,n)
end doend doend doend do; end do; end do
12

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
35 / 253

PA測定結果（N=4096、NB=16）100

時間 (sec)

80

60

40

20

0
Process 0

行列・行列積の計算N=4096,NB=16
L1$⇔L2$間転送回数≒4.3(←65)=1.11×109×16.7÷(8×32×40962)
L2$⇔メモリ間転送回数≒2.4(←0.2)=0.9×109×11.6÷(8×32×40962)
13

ピーク性能比11%↓
ピーク性能比17%
ちなみにIvy Bride E5 2643V2ではNB=64のときピーク性能比28%

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

行列・行列積の性質• ループ1回当たり2演算を大量（NB3回）に繰り返す• 計算に必要なデータは3 NB2語
配列要素aij（or bij）をNB回繰り返し利用
簡単な計算を大量に行うのでレジスタに余裕がある
データの利用回数が多いのでキャッシュにのせれば効果大
上手くいけばレジスタ上のデータも再利用してくれる？

タイリングの効果が出易い
行列・行列積の計算は演算量が計算に必要なデータ量に比べて多い計算
14

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
36 / 253

オンチップメモリとタイリング• 本来の？オンチップメモリの使い方
計算とメモリアクセスのオーバーラップ（そもそも、オーバーラップするのに最低限必要なメモリ帯域が「（アプリケーションが）要求（する）メモリ帯域（B／F）」だったような？）オンチップメモリにのせるには、まずは小分け（タイリング）する必要がある
ユーザの手でオーバーラップさせるのはハードルが高いので• キャッシュメモリの場合、ハードおよびコンパイラが頼り性能が出ればそれでおしまい
出なければ？

• タイル内のデータの利用回数を増やすことを考える
15

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日• プリフェッチはload/storeネックのアプリでは効果が薄い？
• 一番効果が出てほしいのは、そういうアプリだったりする

16

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
37 / 253

ハイブリッド非構造格子の性質
ハイブリッド非構造格子とはピラミッド（4面体）、プリズム（三角柱）、六面体等
種々の格子を組み合わせて形成された空間格子

性質
・複雑形状まわりの格子を精度よく生成し易い
・領域分割が難しい（METISなどPDSを利用）
タイリングには再帰的領域分割が必須
17

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

非構造格子の性質• ランダムアクセス
そんなハイブリッド非構造格子CFDソルバで性能を出すには？

18

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
38 / 253

非構造格子CFDにおける移流項の計算• データの利用回数は10程度で少ない（2次精度）
タイリングによる効果が出難い
再帰的領域分割だけでは、あまり意味がない「袖」まで計算すれば同じデータを利用するループが統合できて利用回数を増やせる（マルチコアクラスタWG）• 演算量はループ1回あたり1,000程度で多い
計算式が複雑で途中結果が大量に発生
物理的に意味のあるループに分割し整理
19

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

本当に早くなる？
試にやってみるにはハードルが高い
とりあえず移流項の計算部分を抜きだして格子点数を変化させてサブリージョンの生成を代用
境界条件の計算は無視
性能をリミットする要因が明確になっていないので
果たして実アプリの傾向を継承しているのか不明
20

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
39 / 253

ループの統合は有効か？
一連の計算の物理的に意味のある
要素計算への分割は可能か？
くらいは見られる？
21

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

おまけ（新システム評価結果の一部）

22

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
40 / 253行列・行列積における配列の静的確保（Static）と動的確保（Dynamic）
StaticDynamic100

ピーク性能比[%]

80

60

40

20

FX1で測定

0
10

100

1,000

10,000

行列サイズN23

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日

タイリングを行った場合の行列・行列積の性能
演算量と実行時間から計算した結果（tiling）とPAによる測定結果（tiling PA）
tilingtilingPA

25

ピーク性能比[%]

20

15

10

5

FX1で測定

0
1

10

100

1,000

タイルの数NT（行列サイズN=4096固定）
24

SS研ポストペタアプリ性能WG第4回会合資料2014年12月10日
41 / 253

有限体積法における再帰参照とSIMD化
宇宙航空研究開発機構
坂下 雅秀

SS研ポストペタアプリ性能WG第7回会合資料2015年10月8日

有限体積法における典型的な定義参照関係：勾配の計算
例： Green-Gauss公式（Gaussの発散定理）
1

xdV

x

d
S


x

x  dS
V
S

V S
1
1
xi  x j S  n

x


i
差分表記
Vi j 2
CVj
xj

CVi
xi
(xi +xj)S・n/2

CVj’
xj’
(xi +xj’)S・n/2(xi+xj)S・n/2はControl Volume（CV）表面で求まり
CViとCVj両方の計算で参照される
242 / 253

コーディング・パターン
パターンI

パターンIIdo icol=1,num_color
do jcol=col_list(1,icol),col_list(2,icol)
iface =face_list(jcol,icol)
icl=face2CV(1,iface)
icr=face2CV(2,iface)wdx=0.5*(x(icl)+x(icr))*Sn(iface)dx(icl)=dx(icl)+wdx
dx(icr)=dx(icr)+wdx
end doend dodo iface=1,num_face
icl=face2CV(1,iface)
icr=face2CV(2,iface)wdx=0.5*(x(icl)+x(icr))*Sn(iface)dx(icl)=dx(icl)+wdx
dx(icr)=dx(icr)+wdx
end do全ての面 iface で(xi+xj)Sn/2を計算
同時に左右のCVに計算結果を配る“パターンI”の再帰参照をcolorlingにより回避•非構造格子向き•スレッド並列化可能•収束性低下？
•キャッシュミス率高•もっとも素直なコーディング•スレッド並列化不可（再起参照）•キャッシュミス率低3

コーディング・パターン
パターンIII

パターンIVdo iface=1,num_face
icl=face2CV(1,iface)
icr=face2CV(2,iface)
wdx(iface)=0.5*(x(icl)+x(icr))*Sn(iface)end do!$omp parallel do schedule(dynamic,1000)
do icv=1,num_CV
do ifc=1,num_face_into_CV(icv)
iface=CV2face(ifc,icv)
dx(icv)=dx(icv)+wdx(iface)end doend dodo icv=1,num_CV
do ifc=1,num_face_into_CV(icv)
iface =CV2face(1,ifc,icv)
icr=CV2face(2,ifc,icv)
dx(icv)=dx(icv)+0.5*(x(icv)+x(icr))*Sn(iface)end doend do全ての面 iface で(xi+xj)Sn/2 を計算作業用配列に保存したのち各CVで和を計算

全てのCVで一度にΣ(xi+xj)Sn/2を計算•構造格子向き（二番目のloopが展開可能）•一番目のloopは高速・二番目のloopは低速•openMP(OMP)の動的割り当て適用により性能改善•スレッド並列化可能•計算量2倍•スレッド並列化可能•キャッシュミス率低443 / 253

非構造格子CFDソルバの処理の流れ
Ｎａｖier‐Stokes方程式 → 連立方程式：Ax=b・右辺（ベクトル）bの計算
勾配▽xi計算
CVi表面における物理量xf
勾配制限関数Ψiの計算
xf = xi+Ψi▽xi(ri-rf)
移流項（advection flux）の計算
粘性項（viscous flux）の計算
・時間積分
係数行列Aは配列に保存されずここで計算される（matrix free form）

LU‐SGS（部分因数分解による近似LU分解）陰解法

5

移流項（advection）の計算
No.
修正箇所
0 (ASIS)時間
5.9secSIMD SWP
ピーク比
3.9%

1 内部サブルーチンを手動でインライン展開

5.9sec

3.9%

2 If文の削除（置き換え）
最内側ループのインライン展開

3.0sec8.1%

3 ループ分割（パターンIII）SWPのOCL文追加

2.2sec

前半：11.4%
後半： 6.5%○○○

その他、‐prefetch_indirectの追加、‐Nrtrapの削除など、最適化オプションの変更を行ったが、変化は0.1%以下。
6
44 / 253

移流項（advection）の計算
No.

修正箇所

時間

ピーク比

0

(ASIS)

5.9sec

3.9%

SIMD

SWP

修正前（ASIS）

7

移流項（advection）の計算
No.
修正箇所
1 内部サブルーチンを手動でインライン展開時間

ピーク比

5.9sec

3.9%

SIMD

SWP

faceloop1: do i_face = 1, n_face
call pre_advection_scheme（再構築）call hllew（リーマン解法）
call post_advection_scheme（流束和分）
end do faceloop1

赤字の部分を手動でインライン展開
もともと、コンパイルオプションで展開するようにしているが、その方法だと、最適化がかからない。
しかし、展開するだけでは、SWPやSIMDが有効とならないため、性能は変わらない

8
45 / 253

移流項の計算（pre_advection_scheme）
修正箇所

時間

2 If文の削除
最内側ループ展開

3.0sec

No.

ピーク比

SIMD

SWP
○

8.1%

flag_neg = max(0,sign(1,pria_update(1)))*max(0,sign(1,pria_update(5)))!ocl unroll(5)do i = 1,5
pria_update_tmp(i,i_face) = flag_neg*pria_update(i) &&+ (1‐flag_neg)*pria(i)end doflag_neg = max(0,sign(1,prib_update(1)))*max(0,sign(1,prib_update(5)))!ocl unroll(5)do i = 1,5
prib_update_tmp(i,i_face) = flag_neg*prib_update(i) &&+ (1‐flag_neg)*prib(i)end do

If文をmax/min/sign関数で置き換える
面ループの中のdoループはocl文でunrolling←最内側ループは!ocl unrollで展開する←乱流モデルの変数は固定にする（例えば、全部２方程式を解く）

移流項（advection）の計算
No.
修正箇所
3 ループ分割（パターンIII）SWPのOCL文追加

時間

ピーク比
前半：11.4%
2.2sec後半： 6.5%

faceloop11: do i_face = 1, n_face
pre_advection_scheme（再構築）
end do faceloop11← 一時的に配列に保存

faceloop12: do i_face = 1, n_face
hllew（リーマン解法）
end do faceloop12← 一時的に配列に保存

cellloop1: do i_cell = 1, n_cell
post_advection_scheme（流束和分）
end do cellloop1

再帰参照を回避すため、
CVループに変更

ループを分割することで、SIMDとSWPが有効になる

46 / 253

SIMD SWP○○

制限関数（limiter）の計算
前半：最大・最小を求める
修正箇所

No.

時間

ピーク比

0

(ASIS)

0.8sec0%

1

外側ループでSWP化

0.5sec0%

2

面ループ→CVループ（パターンIV）

0.2sec

0%

SIMD

SWP
○

○

○

SIMD

SWP

後半：制限関数の計算
修正箇所

No.
0

(ASIS)

1

ループ融合を無効化
ループ展開
ループ分割（パターンIII）

2

時間

ピーク比

3.4sec7.0%

2.6sec9.3%

1.9sec

13.7%

○
○

○

11

制限関数（limiter）の計算前半
No.
0

修正箇所
(ASIS)

時間
0.8sec

修正前（ASIS）

47 / 253

ピーク比
0%

SIMD

SWP

制限関数（limiter）の計算前半
修正箇所

No.

1 ループ融合を無効化
最内側ループの展開

時間

ピーク比

0.5sec

0%

SIMD

SWP
○

do i_face = 1, num_face!ocl LOOP_NOFUSION!ocl unroll(5)do i = 1, num_var! num_var=5, parameter属性, 引数渡し
cell_states_max(i,ia_cell) = max( cell_states_max(i,ia_cell), prib(i) )end do!ocl LOOP_NOFUSION!ocl unroll(5)do i = 1, num_var! num_var=5, parameter属性, 引数渡し
cell_states_min(i,ia_cell) = min( cell_states_min(i,ia_cell), prib(i) )end doend do!ocl loop_nofusionで、ループ融合を無効化!ocl unrollによりループ展開→面ループがSWP化される→実は、unrollだけでいいかも

制限関数（limiter）の計算前半
No.
修正箇所
2 面ループ→CVループ（パターンIV）

時間

ピーク比

SIMD

SWP

0.2sec0%○○

do i_cell = 1, num_cell
flag1 = max(0,sign(1,n_cell2face(i_cell)‐1))
flag2 = max(0,sign(1,n_cell2face(i_cell)‐2))（省略）
i0 = i_celli1 = (1‐flag1)*cell2cell(1,i_cell) + flag1*i_celli2 = (1‐flag2)*cell2cell(2,i_cell) + flag2*i_cell（省略）!ocl unroll(5)do i = 1, 5
cell_states_max(i,i_cell) = max ( cell_states(i,i0), &cell_states(i,i1), &cell_states(i,i2), &cell_states(i,i3), &cell_states(i,i4), &cell_states(i,i5), &cell_states(i,i6))
end doend doCVループに変更することで再帰参照を回避
48 / 253

制限関数（limiter）の計算後半
修正箇所(ASIS)

No.
0

時間
ピーク比
3.4sec
7%

SIMD

SWP

修正前（ASIS）

制限関数（limiter）の計算後半
No.
修正箇所
1 外側ループでSWP化

時間 ピーク比2.6sec9.3%!ocl SWP
faceloop5: do i_face = 1, num_face（省略）!ocl unroll(5)!ocl NOSWP!ocl NOSIMD
do i = 1, num_var! Num_var=5, parameter属性（省略）
slope_limiter(i,ib_cell) = min( slope_limiter(i,ib_cell), phi_tmpb )end doend do faceloop5!ocl unrollにより最内側ループを展開
内部ループのSWP化を無効化
外部ループでSWP化

49 / 253

SIMD

SWP
○

制限関数（limiter）の計算後半
No.

修正箇所

時間

2

ループ分割
（パターンIII）

1.9sec!ocl SWP
faceloop5: do i_face = 1, num_face（省略）!ocl unroll(5)do i = 1, 5
（省略）
phi_tmp(2,i,i_face) =end doend do faceloop5!ocl loop_nofusion!ocl SWP
cellloop5: do i_cell = 1, num_cell（省略）!ocl unroll(5)do i = 1, 5
slope_limiter(i,i_cell) = &&min( (1‐fb1)*phi_tmp(1,i,i1) + fb1*phi_tmp(2,i,i1), &&(1‐fb2)*phi_tmp(1,i,i2) + fb2*phi_tmp(2,i,i2), &&(1‐fb3)*phi_tmp(1,i,i3) + fb3*phi_tmp(2,i,i3), &&(1‐fb4)*phi_tmp(1,i,i4) + fb4*phi_tmp(2,i,i4), &&(1‐fb5)*phi_tmp(1,i,i5) + fb5*phi_tmp(2,i,i5), &&(1‐fb6)*phi_tmp(1,i,i6) + fb6*phi_tmp(2,i,i6) )end doend do cellloop5

ピーク比

SIMD

SWP

13.7%

○

○

面のループ

CVのループ勾配（gradient）の計算
No.

修正箇所

0

(ASIS)

1
2

時間

ピーク比

SIMD

SWP

0.9sec

3.53%

面ループを面ループとCVループに
分割（パターンIII）

前半：0.4sec
後半：0.9sec

前半：5.8%後半：4.2%

前半：○
後半：○

前半：○
後半：×

後半にprefetch

前半：0.4sec
後半：0.6sec

前半：5.8%後半：5.5%

前半：○
後半：○

前半：○
後半：×

とりあえず、このルーチンだけ、高速化できなかった。

18
50 / 253勾配（gradient）の計算
No.
0

修正箇所
(ASIS)

時間
ピーク比
0.9sec
3.53%

SIMD

SWP

修正前（ASIS）

勾配（gradient）の計算
No.
1

修正箇所
ループ分割
（パターンIII）

時間
前半：0.4sec
後半：0.9sec

前半

ピーク比
前半：5.8%後半：4.2%

SIMD

SWP

前半：○ 前半：○
後半：○ 後半：×後半
後半：
jwd8668o‐i "gradient.f90",line 788: 命令数が過剰なため,
ソフトウェ アパイプライニングを適用できません
SWPが効いていないため（？）
後半ループでメモリ待ちが目立つ.

20
51 / 253勾配（gradient）の計算
No.

修正箇所

時間

ピーク比

SIMD

SWP

2

後半にprefetch

前半：0.4sec
後半：0.6sec

前半：5.8%後半：5.5%

前半：○
後半：○

前半：○
後半：×

後半

前半

Prefetch指定によりメモリ待ち改善
SWP化されれば、もう少しはマシになる？

21

粘性項（viscous）の計算
No. 修正箇所
0 (ASIS)
1
2

時間
0.9sec

ピーク比
7.0%0.7sec9.3%
If文削除
ループ分割 前半：0.4sec 前半：14.6%（パターンIII） 後半：0.1sec 後半： 4.6%

SIMD

SWP

前半：○
後半：○

○
前半：○
後半：○

22
52 / 253

粘性項（viscous）の計算
No.
0
1

修正箇所
(ASIS)
If文削除

時間
ピーク比
0.9sec7.0%
0.7sec
9.3%

ASIS

SIMD

SWP
○

IF文削除

SWP化によって演算待ち時間短縮23

粘性項（viscous）の計算
No.
2

修正箇所
ループ分割
（パターンIII）

時間
ピーク比
前半：0.4sec 前半：14.6%
後半：0.1sec 後半： 4.6%

前半

SIMD

SWP

前半：○
後半：○

前半：○
後半：○

後半

SIMD化によってさらに高速化24
53 / 2532.3 惑星磁気圏 MHD コードの性能評価
京都大学 学術情報メディアセンター
深沢 圭一郎2.3.1 はじめに
MHD シミュレーションはプラズマの振る舞いを正確に記述できる Vlasov 方程式の近似から求められる MHD 方程式を利用したシミュレーションである。MHD 方程式は Vlasov 方程式を近似する際に、速度空間を落とすことで、計算する次元数を減らし、プラズマの大規模構造を計算する際によく利用されている。惑星磁気圏 MHD コードは惑星の磁場の勢力範囲である磁気圏をグローバルに解くシミュレー
ションコードである。太陽からのプラズマの流れ（太陽風）と惑星の磁場が相互作用することで形作られる惑星磁気圏は、名に見える現象ではオーロラに代表されるように様々な電磁気現象が起きている。
これらは宇宙空間で運用されている GPS などの衛星や宇宙ステーションだけで無く、誘導電流などの形
で地上にも影響を与えている。これらの現象は宇宙天気と呼ばれており、世界中で広く研究されている。
惑星磁気圏 MHD コードはこの宇宙天気予報において基本となるシミュレーションコードとして利用されている。この惑星磁気圏 MHD コードはベクトル機全盛時代から利用されているが、近年では超並列スカラ計算機にも対応し、様々な計算機上で利用されている。今回ポストペタスケール計算に向けて、
京コンピュータの後継機である FX10 とさらにその後継機である FX100 において、惑星磁気圏 MHD コ
ードの性能評価を行った。
2.3.2 プログラム概要
MHD 方程式は以下のようになる。

∂ρ= −∇ ⋅ ( vρ )
∂t
∂v
1
1
= − ( v ⋅ ∇ ) v − ∇p + J × B
ρ
ρ
∂t
∂p
= −( v ⋅ ∇) p − γp∇ ⋅ v∂t∂B= ∇ × ( v × B)∂t(1)

上から、連続の式、運動方程式、圧力変化の式（エネルギーの式）、最後が磁場の誘導方程式となる。
簡単に言えば、電磁場を考慮した流体力学方程式と呼べる。MHD 方程式を解く数値計算法としては、

Ogino ら[1992]によって開発された Modified Leap Frog（MLF）法という差分法を使用する。これは最初の 1 回を two step Lax-Wendroff 法で解き、続く （l － 1）回を Leap Frog 法で解き、その一連の手続きを繰り返す手法である。l の値は数値的に安定の範囲で大きい方が望ましいので、数値精度の線形計
算と予備的シミュレーションから l = 8 に選んでいる。惑星磁気圏 MHD コードは直交格子を利用しており、いわゆる stencil 計算である。並列は MPI と OpenMP を利用し、領域分割を行っている。1、２、３次元分割を性能評価に利用している。通信は基本的には袖領域の隣接通信のみである。

54 / 2532.3.3 測定環境
性能測定には、東京大学 FX10、名古屋大学 FX100 を利用した。各計算機の構成は表 1 の通りである。
測定には、最大で FX10 を 4800 ノード（76,800 コア）と FX100 を 512 ノード（16,384 コア）を利用した。
表 1. FX10、FX100 のシステム構成

PRIMEHPC FX10PRIMEHPC FX100

Architecture

16 cores SPARC64 IXfx

32 cores SPARC64 XIfx

Frequency

1.848 GHz (236.544 GFlops)

2.2 GHzCache

L1: 32 KB/core

L1: 64 KB/core

L2: 12 MB/CPU

L2: 24 MB/CPU

Memory Band width

85 GB/s /CPU (=node)

240 x2 (in/out) GB/s /CPU

B/F

0.36

0.21 or 0.42

Number of CPUs

1

1

Memory size

32 GB

32 GB

Number of nodes

4,800 (76,800 cores)

2,880 (92,1600 cores)

Rmax

1.135 PFlops

3.244 PFlops

Node comm。

Tofu Interconnect (5 GB/s)

Tofu 2 (12.5 GB/s)

CPU

Node
System(1126.4 GFlops)

2.3.4 測定結果
FX10 において、MHD コードの性
能評価結果を図 1 に載せる。ここでは
1、2、3 次元領域分割と 3 次元領域分割において計算する配列並びが
f(i,j,k,m)：typeA と f(m,i,j,k)：typeBの場合を評価した。最も性能が高かったのは 3 次元領域分割 typeB で、約210TFlops（実行効率 19%）となった。
一方で配列の順序が違うだけのtypeA では 110TFlops と半分近くの性能になっている。この二つの L2 キャッシュミス率などを調べた結果、表2 のようになっており、L2 キャッシュ

図１

FX10 における性能測定結果

ミス率とメモリバンド幅の違いが性能の違いに効いていることがわかる。また、L1 キャッシュスラッシ
ングにより typeA の性能が劣化していることも分かっている。最も性能の高い 3 次元領域分割 typeB に式の共通化、配列の次元削減とループ融合といった最適化を施した結果、32 ノード利用時に実行効率が30%となった。

55 / 253表 2 3 次元領域分割 typeA と B における SIMD 化率、L2 demand キャッシュミス率、メモリバンド幅

Array type

SIMD efficiency [%]L2 demand cache miss [%]Memory bandwidth [GB/s]

Type A

65.58

19.81

7.49

Type B

54.26

3.64

24.94

FX100 での性能評価結果を図 2 に載せる。ここでは FX10 での最適化は加えていない。最も性能が高くなったのは 1 次元領域分割（実行効率 13％）で、次が 3 次元領域分割 typeA(同10.6%)であった。FX10 で最も性能の高かった typeB は FX100 では性能が最も出なかった。このように FX10と FX100 はコードに対する振る舞いが異なり、FX100 ではベクトル的なコードが速いという結果になった。今
度は 3 次元領域分割 typeA に対して
ループや文の分割、プロセスと計算サ

図2

FX100 における性能測定結果

イズの調整、配列の分割、空間タイリングなどを施したところ、16.7%の実行効率を達成することができた。
2.3.5 まとめ惑星磁気圏を解く MHD シミュレーションコードを用いて、京の後継機種である FX10 と FX100 の性
能評価を行った。基本性能測定として、1 次元、2 次元、3 次元領域分割 typeA と typeB を用いて、それぞれの性能を測定した。最も性能が高くなったのは 3 次元領域分割 typeB（実行効率 19%）であり、typeAと比べて 2 倍程度の性能差があった。これは HPC2500 から続く SPARC64v 系の CPU と同様の傾向であり、キャッシュヒットを考慮したコードの性能が高いことを示している。最も性能が高かった 3 次元
領域分割 typeB にキャッシュをより効率よく利用できるようないくつか最適化を加えたところ、最大で実行効率が 30%まで向上した。
一方で FX100 に対して、FX10 と同様の性能測定を行ったところ、1 次元領域分割がもっとも性能が高く（実行効率 13％）、次に 3 次元領域分割 typeA（10.6%）となった。FX10 で最も性能の高かった 3
次元領域分割 typeB は FX100 では逆に最も性能が低かった。これはキャッシュヒットを考慮するよりも、ベクトル化を考慮した方が良いことを示している。FX100 では 3 次元領域分割 typeA に最適化を加えた。
ループや文の分割によりコンパイラの最適化が促進され、プロセス分割の調整、配列分割やサイクリッ
ク並列化により L2 キャッシュミスが減少し、最終的には 16.7%の実行効率となった。
また、今回の FX100 での結果を他の計算機システムと比較すると、1CPU あたりで SX-ACE の 1.6 倍程度の性能になっており、KNC の Xeon Phi の 2 倍程度の性能となっていた。

56 / 253惑星磁気圏
MHDコードの性能評価
深沢圭一郎
京都大学学術情報メディアセンター

SS研SS研ポストペタアプリ性能WG【FX10】 TypeA timer71でL1Dキャッシュスラッシング
[秒]
200
180
160
140
120
100
80
60
40
20
0

ソース(一部)
340 3 p v do i = is, ie1
341 3 p v x =0.5*hx*float(2*(iss+i)-nx2+2*nxp)
342 3 p v ra2 = x * x + y * y + z * z
343 3 p v ra2 = max(ra2, ra_i2)
344 3 p v ra3 = ra2 * sqrt(ra2)346 3 p v u(i,j,k,8) = u(i,j,k,8)&347 3+ dx1 * (&348 3
f(i+1,j+1,k+1,4) * f(i+1,j+1,k+1,6) &349 3- f(i+1,j+1,k+1,2) * f(i+1,j+1,k+1,8) &350 3+ f(i+1,j,k+1,4) * f(i+1,j,k+1,6)&351 3- f(i+1,j,k+1,2) * f(i+1,j,k+1,8)&352 3+ f(i+1,j+1,k,4) * f(i+1,j+1,k,6)&353 3- f(i+1,j+1,k,2) * f(i+1,j+1,k,8)&354 3+ f(i+1,j,k,4) * f(i+1,j,k,6)&(省略)

FX10 TypeA timer71

浮動小数点
ロードキャッ
シュアクセス待ちtimer71 全体
TypeA
timer71

L1D ミス率(/ロード・ストア
数)

L1D ミス dm率(/L1D ミス数)

L1Dミス数2.62%

33.15%

4.96E+10

配列が連続アクセスであるにも関わらずL1Dキャッシュミス率が高く(目安：3.125%以上)、L1Dキャッシュミスのデマンドの内訳が高い(目安：20%以上) ストリーム数が58個と多い

2インデックスずれているが2ライン（インデックス）先をプリフェッチする影響でL1Dキャッシュスラッシングが発生している。

L1D競合ツール結果(一部)配列名
f(i,j+1,k+1,5)f(i,j,k,8)
Copyright 2015 FUJITSU LIMITED
ff(i,j,k,7)⇒ L1Dキャッシュスラッシングの疑い有り

57 / 253

アドレス

Index

0x9BB812F0

37→39

0xF861D3F8
0x7FEC2469388

2

39
39

【FX10】 TypeA timer151でL1Dキャッシュスラッシング[秒]160

ソース(一部)
1362 3 p do i = is1, ie1(省略)1371 3 p f(i,j,k,8)=f(i,j,k,8)*x2+ff(i,j,k,8)*(1.0-x2)
1372 3 p f(i,j,k,7)=f(i,j,k,7)*x2+ff(i,j,k,7)*(1.0-x2)
1373 3 p f(i,j,k,6)=f(i,j,k,6)*x2+ff(i,j,k,6)*(1.0-x2)
1374 3 p f(i,j,k,5)=f(i,j,k,5)*x2+ff(i,j,k,5)*(1.0-x2)
1375 3 p f(i,j,k,4)=f(i,j,k,4)*x2+ff(i,j,k,4)*(1.0-x2)
1376 3 p f(i,j,k,3)=f(i,j,k,3)*x2+ff(i,j,k,3)*(1.0-x2)
1377 3 p f(i,j,k,2)=f(i,j,k,2)*x2+ff(i,j,k,2)*(1.0-x2)
1378 3 p f(i,j,k,1)=f(i,j,k,1)*x2+ff(i,j,k,1)*(1.0-x2)
1379 3 !
1380 3 p end do

FX10 TypeA timer151

140
120
100

浮動小数
点ロード
キャッ
シュアク
セス待ち

80
60
40
20

２インデックスずれているが２ライン（インデックス）先をプリフェッチする影響でL1Dキャッシュスラッシングが発生している。

0

Loop (line 1048‐1354 1362‐1380)

L1D競合ツール結果(一部)TypeA

L1D ミス率(/ロード・ストア
数)

L1D ミス dm率(/L1D ミス数)

L1Dミス数timer151

9.62%

55.81%

7.51E+10

配列名

Index

アドレス

ff(i,j-1,k,2)

0x7FE27C5D0B0

34→36

u(i,j,k,5)0x192E29098

34→36

u(i,j-1,k1,8)

0x7FE08DF5120

36p(i,j,k,2)
Copyright 2015 FUJITSU LIMITED

0x7FCD3DDD198

配列が連続アクセスであるにも関わらずL1Dキャッシュミス率が高く(目安：3.125%以上)、L1Dキャッシュミスのデマンドの内訳が高い(目安：20%以上) ストリーム数が91個と多い⇒ L1Dキャッシュスラッシングの疑い有り

3

36式の共通化＠FX10
計算式が長いとコンパイラが適切にスケジューリングできない場合がある
u(8,i,j,k) = u(8,i,j,k)+ dx1 * (f(4,i+1,j+1,k+1) * f(6,i+1,j+1,k+1)‐ f(2,i+1,j+1,k+1) * f(8,i+1,j+1,k+1)+ f(4,i+1,j ,k+1) * f(6,i+1,j ,k+1)‐ f(2,i+1,j ,k+1) * f(8,i+1,j ,k+1)+ f(4,i+1,j+1,k ) * f(6,i+1,j+1,k )‐ f(2,i+1,j+1,k ) * f(8,i+1,j+1,k )+ f(4,i+1,j ,k ) * f(6,i+1,j ,k )‐ f(2,i+1,j ,k ) * f(8,i+1,j ,k )‐ f(4,i ,j+1,k+1) * f(6,i ,j+1,k+1)+ f(2,i ,j+1,k+1) * f(8,i ,j+1,k+1)‐ f(4,i ,j ,k+1) * f(6,i ,j ,k+1)+ f(2,i ,j ,k+1) * f(8,i ,j ,k+1)‐ f(4,i ,j+1,k ) * f(6,i ,j+1,k )+ f(2,i ,j+1,k ) * f(8,i ,j+1,k )‐ f(4,i ,j ,k ) * f(6,i ,j ,k )+ f(2,i ,j ,k ) * f(8,i ,j ,k )ffff11 = f(4,i+1,j+1,k+1) * f(6,i+1,j+1,k+1)‐ f(2,i+1,j+1,k+1) * f(8,i+1,j+1,k+1)+ f(4,i+1,j,k+1) * f(6,i+1,j,k+1)‐ f(2,i+1,j,k+1) * f(8,i+1,j,k+1)
ffff21 = f(4,i+1,j+1,k) * f(6,i+1,j+1,k)‐ f(2,i+1,j+1,k) * f(8,i+1,j+1,k)+ f(4,i+1,j,k) * f(6,i+1,j,k)‐ f(2,i+1,j,k) * f(8,i+1,j,k)
ffff31 = f(4,i,j+1,k+1) * f(6,i,j+1,k+1)‐ f(2,i,j+1,k+1) * f(8,i,j+1,k+1)+ f(4,i,j,k+1) * f(6,i,j,k+1)‐ f(2,i,j,k+1) * f(8,i,j,k+1)
ffff41 = f(4,i,j+1,k) * f(6,i,j+1,k)‐ f(2,i,j+1,k) * f(8,i,j+1,k)+ f(4,i,j,k) * f(6,i,j,k)‐ f(2,i,j,k) * f(8,i,j,k)

&

)

&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&

&
&
&
&
&
&
&
&
&
&
&
&

!

Asis:
192.231sec
最適化後:156.230sec
1.23倍の性能向上

u(8,i,j,k) = u(8,i,j,k)+ dx1 * (ffff11 + ffff21‐ ffff31 ‐ ffff41)‐ dy1 * (ffff12 + ffff22‐ ffff32 ‐ ffff42
)

&
&
&
&
&
&
&
&

4
58 / 253

配列の次元削減とループ融合＠FX10
必要最低限の配列次元にすることで、効率化
do k = ks, ke1
do j = js, je1!OCL LOOP_NOFUSION
do i = is, ie1
ff_wk(1,i) = u(1,i,j,k)
ff_wk(2,i) = u(2,i,j,k)
ff_wk(3,i) = u(3,i,j,k)
ff_wk(4,i) = u(4,i,j,k)
ff_wk(5,i) = u(5,i,j,k)
ff_wk(6,i) = u(6,i,j,k)
ff_wk(7,i) = u(7,i,j,k)
ff_wk(8,i) = u(8,i,j,k)
end do!
do i = is, ie1・・・・

do k = ks, ke1
do j = js, je1
do i = is, ie1
do m = 1, nb
ff(m,i,j,k) = u(m,i,j,k)
end doend do!
do i = is, ie1
・
・
・
・

Asis:
192.231sec
最適化後:172.109sec
1.12倍の性能向上

5

最適化結果＠FX10
今までの最適化すべてを適用した
4ノード利用の結果（計算サイズは800×800×800）•

Flat MPIは64プロセス（4×4×4）
asis:192.321sec（22.66%）→135.242sec（28.59%）• Hybrid MPI：4プロセス（2×2×1）+16スレッド
asis:192.570sec（22.78%）→133.895sec（27.67%）

32ノード利用の結果（計算サイズは1600×400×400）•

Flat MPIは512プロセス（8×8×8）
asis:12.783sec（21.05%）→8.765sec（27.34%）• Hybrid MPI：64プロセス（4×4×4）+8スレッド
asis:13.247sec（20.51%）→7.672sec（30.34%）

659 / 253

結果概要• FX10用2way SIMDバイナリを
FX100で実行すると、1.77倍高速化• 4way SIMDバイナリに再翻訳すると、1.30倍高速化• プロセス分割調整、ループや文の分割の最適化を行うと、1.54倍高速化

30

計算時間 (秒)

25
20

1.77倍

15

1.30倍

アプリの表示性能:
6.019 Tflops※

1.54倍

10
5
0
オリジナル

オリジナル

2 way SIMD

2 way SIMD

FX10 64ノード

オリジナル

最適化後

4 way SIMD
FX100 32ノード※:コンパイラ最適化による演算数変化は考慮せず
7

FX10とFX100の比較
サイクルアカウンティング結果を比較
FX100

FX100

25

25

20

20

20

15

15

15

ｷｬｯｼｭｱｸｾｽ
待ち時間 10

10

10

5

5

5

asisコードで測定
FX100では、キャッシュアクセス待ち
時間が減少し、性能が向上• L1D$容量(32→64KB)、ウェイ数(2→4)、
およびスループットの倍増が貢献• ラインサイズ2倍(128→256B)のため、
連続アクセス時はミス率半減が期待値

FX10
FX100
(2way SIMD)

FX100(4way SIMD)

ｷｬｯｼｭｱｸｾｽ
待ち時間

L1D$
ミス率

13.9秒

3.95%

6.3秒

1.54%

4.4秒

1.53%

[秒] FX1025

060 / 253

Thread 0 Th

(2way SIMD) (4way SIMD)

0

Thread 0 Th

0Thread
8 0 Thループや文の分割による性能向上
ステンシル計算だが、L1D$ミス率が連続アクセスより高い• データ再利用により、連続アクセス時以下が期待値→L1D$スラッシング?
• FISSION_POINT指示行の挿入により、ループ分割• ループ分割: ループ分割を人手で実施• 文の分割: 右辺が長い代入文を、複数の部分式からなる文に人手で分割最適化による性能向上 (FX100 32ノード)
12⇒コンパイラ最適化が促進(②→⑤)
1.07倍

10

計算時間 (秒)L1D$ミス率

1.05倍

8

②

1.71%

②＋FISSION_
POINT指示

1.57%

⑤

1.86%

2

⑤＋ループ分割

1.81%

0

1.27倍

6
4

①:ｵﾘｼﾞﾅﾙ

まだ高く、改善余地あり

②:①＋
③:②＋
④:③＋
ﾌﾟﾛｾｽ分割 FISSION_ 文の分割の調整 POINT指示

⑤:②＋
⑥:⑤＋
文の分割 ループ分割⑦:⑥＋
ｻｲｸﾘｯｸ
9 並列化

プロセス分割の調整、サイクリック並列化、他
プロセス分割 格子点数/プロセス

プロセス分割の調整

調整前• スレッド並列化対象ループの調整後繰返し数をスレッド数の倍数に• 最内ループの繰返し数を多めに4×4×4

200×200×200

1×32×2800×25×400!$OMP PARALLEL DO SCHEDULE(STATIC,1) ...
do k = ks, ke1

サイクリック並列化• Z方向の差分計算で参照する
12
データのスレッド間共有を促進

最適化による性能向上 (FX100 32ノード)

1.14倍

L2$
ミス率

メモリ
スループット
/ノード

⑥

1.09%

167.7GB/秒⑥＋ｻｲｸﾘｯｸ
並列化

0.95%

140.4GB/秒

余力があるため、性能向上幅が小計算時間 (秒)

10

1.01倍

8
6
4
2
0
①:ｵﾘｼﾞﾅﾙ61 / 253

②:①＋
③:②＋
④:③＋
ﾌﾟﾛｾｽ分割 FISSION_ 文の分割の調整 POINT指示

⑤:②＋
⑥:⑤＋
文の分割 ループ分割

10

⑦:⑥＋
ｻｲｸﾘｯｸ
並列化

配列の分割配列f(nx,ny,nz,8)をf1(nx,ny,nz,4)とf2(nx,ny,nz,4)に分割
real ::
real ::

real :: f1(0:nxx+1,0:nyy+1,0:nzz+1,4)
real :: f2(0:nxx+1,0:nyy+1,0:nzz+1,4)
real :: u1(0:nxx+1,0:nyy+1,0:nzz+1,4)
real :: u2(0:nxx+1,0:nyy+1,0:nzz+1,4)f(nx2, ny2, 0:nzz+1, 8)u(nx2, ny2, 0:nzz+1, 8)!
u(i,j,k,8) = u(i,j,k,8)+ dx1 * (f(i+1,j+1,k+1,4) * f(i+1,j+1,k+1,6)‐ f(i+1,j+1,k+1,2) * f(i+1,j+1,k+1,8)+ f(i+1,j,k+1,4) * f(i+1,j,k+1,6)‐ f(i+1,j,k+1,2) * f(i+1,j,k+1,8)+ f(i+1,j+1,k,4) * f(i+1,j+1,k,6)‐ f(i+1,j+1,k,2) * f(i+1,j+1,k,8)+ f(i+1,j,k,4) * f(i+1,j,k,6)‐ f(i+1,j,k,2) * f(i+1,j,k,8)‐ f(i,j+1,k+1,4) * f(i,j+1,k+1,6)+ f(i,j+1,k+1,2) * f(i,j+1,k+1,8)‐ f(i,j,k+1,4) * f(i,j,k+1,6)+ f(i,j,k+1,2) * f(i,j,k+1,8)‐ f(i,j+1,k,4) * f(i,j+1,k,6)+ f(i,j+1,k,2) * f(i,j+1,k,8)‐ f(i,j,k,4) * f(i,j,k,6)+ f(i,j,k,2) * f(i,j,k,8) )

&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&

!
u2(i,j,k,4) = u2(i,j,k,4)+ dx1 * (f1(i+1,j+1,k+1,4) * f2(i+1,j+1,k+1,2)‐ f1(i+1,j+1,k+1,2) * f2(i+1,j+1,k+1,4)+ f1(i+1,j,k+1,4) * f2(i+1,j,k+1,2)‐ f1(i+1,j,k+1,2) * f2(i+1,j,k+1,4)+ f1(i+1,j+1,k,4) * f2(i+1,j+1,k,2)‐ f1(i+1,j+1,k,2) * f2(i+1,j+1,k,4)+ f1(i+1,j,k,4) * f2(i+1,j,k,2)‐ f1(i+1,j,k,2) * f2(i+1,j,k,4)‐ f1(i,j+1,k+1,4) * f2(i,j+1,k+1,2)+ f1(i,j+1,k+1,2) * f2(i,j+1,k+1,4)‐ f1(i,j,k+1,4) * f2(i,j,k+1,2)+ f1(i,j,k+1,2) * f2(i,j,k+1,4)‐ f1(i,j+1,k,4) * f2(i,j+1,k,2)+ f1(i,j+1,k,2) * f2(i,j+1,k,4)‐ f1(i,j,k,4) * f2(i,j,k,2)+ f1(i,j,k,2) * f2(i,j,k,4) )Asis:
19.82sec
分割後: 18.71sec
1.06倍の性能向上*SB Xeonでは1.37倍
11

タイリング
ループをブロック化
real ::
real ::

do kt = ks, ke1, kb
do jt = js, je1, jb
do it = is, ie1, ib
do k = kt, min(ke1, kt+kb‐1)
do j = jt, min(je1, jt+jb‐1)
do i = it, min(ie1, it+jb‐1)

f(nx2, ny2, 0:nzz+1, 8)u(nx2, ny2, 0:nzz+1, 8)!
u(i,j,k,8) = u(i,j,k,8)+ dx1 * (f(i+1,j+1,k+1,4) * f(i+1,j+1,k+1,6)‐ f(i+1,j+1,k+1,2) * f(i+1,j+1,k+1,8)+ f(i+1,j,k+1,4) * f(i+1,j,k+1,6)‐ f(i+1,j,k+1,2) * f(i+1,j,k+1,8)+ f(i+1,j+1,k,4) * f(i+1,j+1,k,6)‐ f(i+1,j+1,k,2) * f(i+1,j+1,k,8)+ f(i+1,j,k,4) * f(i+1,j,k,6)‐ f(i+1,j,k,2) * f(i+1,j,k,8)‐ f(i,j+1,k+1,4) * f(i,j+1,k+1,6)+ f(i,j+1,k+1,2) * f(i,j+1,k+1,8)‐ f(i,j,k+1,4) * f(i,j,k+1,6)+ f(i,j,k+1,2) * f(i,j,k+1,8)‐ f(i,j+1,k,4) * f(i,j+1,k,6)+ f(i,j+1,k,2) * f(i,j+1,k,8)‐ f(i,j,k,4) * f(i,j,k,6)+ f(i,j,k,2) * f(i,j,k,8) )

&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&

!
u(i,j,k,8) = u(i,j,k,8)&+ dx1 * (&f(i+1,j+1,k+1,4) * f(i+1,j+1,k+1,6) &‐ f(i+1,j+1,k+1,2) * f(i+1,j+1,k+1,8) &&+ f(i+1,j,k+1,4) * f(i+1,j,k+1,6)‐ f(i+1,j,k+1,2) * f(i+1,j,k+1,8)&+ f(i+1,j+1,k,4) * f(i+1,j+1,k,6)&‐ f(i+1,j+1,k,2) * f(i+1,j+1,k,8)&+ f(i+1,j,k,4) * f(i+1,j,k,6)&‐ f(i+1,j,k,2) * f(i+1,j,k,8)&‐ f(i,j+1,k+1,4) * f(i,j+1,k+1,6)&+ f(i,j+1,k+1,2) * f(i,j+1,k+1,8)&‐ f(i,j,k+1,4) * f(i,j,k+1,6)&+ f(i,j,k+1,2) * f(i,j,k+1,8)&‐ f(i,j+1,k,4) * f(i,j+1,k,6)&+ f(i,j+1,k,2) * f(i,j+1,k,8)&&‐ f(i,j,k,4) * f(i,j,k,6)

Asis:
19.82sec
最適化後:42.69sec
2.5倍の性能劣化
PAによると、SIMD化がうまくいっていない。
1262 / 253

&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&

Performance measurement of MHD code
Comparison of FX100 with other computer systems
Core/CPUSX-ACE

Suitable
CPU
Efficiency
domain[%]decomposition architecture

65.50

29.20

114.0

45

3D_A

Vector262144/32768 4194.30

914.12

27.9

22

3D_B

FX10

76800/4800

1135.41234.59

48.9

21

3D_B

SPARC64
VIIIfxSPARC64 IXfx

FX100

16384/512576.72

91.49

178.7

17

3D_A

SPARC64 XIfx

RX200S6

864/144

10.13

3.51

24.4

35

3D_A

CX400

23616/2952

510.11104.23

35.3

20

3D_A

Xeon
(Westmere)
Xeon (SB)

HA800023160/1930

500.26

83.42

43.2

17

2D

Xeon (IB)

XC30-HSW

448/32

16.49

1.37

42.8

8

2D

Xeon (HSW)

SR16000/L2

1344/672

25.27

5.38

8.0

21

3D_B

POWER6

Xeon Phi 5120

60/1

1.00

0.08

84.0

8.4

3D_A

Knights Corner

Tesla K20X

896/1

1.31

0.15

153.3

11.7

3D_A

KeplerK

1024/256

Rpeak
Rmax
Rpeak
/CPU
[TFlops] [TFlops] [GFlops]

13

63 / 2532.4 LexADV-AutoMT および AutoLinAS ライブラリの性能評価
諏訪東京理科大学

河合浩志

2.4.1 はじめに本研究では、著者を含む研究グループ ADVENTURE において現在あらたに開発中のLexADV フレームワークについて、そのコンポーネントである AutoMT および AutoLinAS
ライブラリの各種 HPC プラットフォームにおける性能ベンチマークを行った。
エクサスケールコンピュータ等の次世代の並列計算機アーキテクチャにおいて、大規模な数値計算データ処理を必要とする実アプリケーションが高い演算効率を得るためには、
プ$ロセッサやメモリなどハードウェアが持つ階層構造を考慮したプログラミングモデルを採用することが必要である。それに対し、ADVENTURE プロジェクトにおいてこれまで開発されてきた HDDM（Hierarchical Domain Decomposition Method、階層型領域分割法）の技術を応用した、大規模数値計算データ処理ライブラリの研究開発が現在、JST
CREST からの支援をうけた HDDMPPS プロジェクト（プロジェクトリーダー：東洋大、
塩谷隆二教授）において行われている。具体的には、「連続体力学向け DSL」、「DDM ソルバーライブラリ」、「DDM 入出力ライブラリ」、そして「連続体力学系シミュレータ」の 4
つの研究項目における研究開発が進められている。ここでは、大規模な数値計算データに対し各種 HPC アーキテクチャに応じてマルチレベルの多階層の領域分割を行うこと、またこれに基づく多階層計算格子データの生成，操作および I/O をつかさどるライブラリを用意する。そしてこれらをもとに、大規模分散並列計算で実績のある構造・熱・流体・電磁場など複数の FEM（Finite Element Method，有限要素法）解析ソフトウェアを備えている
オープンソース CAE ソフトウェア ADVENTURE システムを作り直すことを最終的に目指している。
本性能ベンチマークにおいてとりあげる AutoMT（「おてもと」）および AutoLinAS（「おとりなし」）についてであるが、これらはそれぞれ、連続体力学分野向け DSL（Domain
Specific Language：特定問題分野向けに特化した計算機言語）、および、HDDM 並列ソルバーライブラリにおける、HPC アーキテクチャごとの差を吸収するための低レベルインタ
ーフェイスとなっている。これらの部分における性能特性は、LexADV フレームワークや将来の ADVENTURE システムのパフォーマンスを決定する重要ポイントになると思われる。
2.4.2 有限要素解析コードのＨＰＣ環境向け実装
有限要素法に基づく構造解析ソルバーは対象となる人工物・構造物の機能や応答、安全性、健全性などを評価するためのツールであり、CAE 技術の最重要コンポーネントとして今やモノづくりにとって不可欠なものとなっている。産業界において現在、例えば自動車

64 / 253

の騒音・振動解析や衝突解析、金型のバーチャルマニュファクチャリング、航空機や船舶の構造健全性評価、建物やプラントの耐震解析など、多種多様なモノづくり・設計シーン
での CAE 技術の普及が進むと同時に、シミュレーション自体のさらなる高精度化とモデルの大規模化が求められている。
大規模構造解析のニーズにはさまざまなものがあるが、一例として、原子力プラントの耐震解析を挙げる。本事例では、鉄筋コンクリート壁、配管、圧力容器、燃料集合体などすべてがソリッド要素で表現されている。解析規模はプラント全体と付近の地盤を合わせて数百億自由度と見積もられ、原子炉圧力容器単体でも数十億自由度を要する。解析は動弾塑性解析であり、数千から数万ステップの計算が必要となる。
有限要素法を用いた構造解析の計算手法や解析の分類としては、線形弾性解析、弾塑性
解析、振動解析、熱応力解析、衝撃解析、塑性加工解析など多岐にわたる。ここではこれらを、HPC 技術との関連という見地から、連立一次方程式を解かないもの（陽解法系）と、連立一次方程式を解くもの（陰解法系）の２つに分類する。前者の場合、各有限要素の単位で得られる情報だけを用いた行列ベクトル積が主要な演算パターンとなり、計算時間の大半は要素剛性行列評価や応力積分などの要素単位での計算処理に割かれる。一方、後者の場合、まず各要素の要素剛性行列を用いて、全体剛性行列と呼ばれる比較的大サイズの疎行列を組み上げる。非定常問題における陰解法ソルバーの場合、これに関する連立一次方程式を時間ステップあるいは非線形ステップごとに解くことになる。なおこれは、静解
析、固有値解析含め、解析ソルバー内に連立一次方程式の解法が組み込まれているもの全般についてもあてはまる。数千万から数億自由度クラスの大規模解析の場合には、もっぱ
ら反復型解法の系統が用いられる。その際、大規模な連立一次方程式を解くための超並列アーキテクチャ向けアルゴリズムに関して、並列反復法ソルバーおよび領域分割法の二つが考えられる。
並列反復法ソルバーでは、対称正定値であれば CG 法、非対称であれば Bi-CGSTAB あ
るいは GMRES 法などにより、全体剛性行列に関する連立一次方程式を解く。構造解析では一部の非線形問題を除き、対称正定値行列を扱うことが多い。一方、構造物の大型化あるいは軽量化により、梁や板状の薄い形状を扱うことも多く、この場合係数行列の条件数は悪化する。したがって、強力な前処理が必要とされることが多い。
並列反復法ソルバーでは、行列ベクトル積が繰り返される。有限要素法の場合、これは三種類の方法により実装することができる。まず、係数行列である全体剛性行列を要素剛性行列から組み上げ、その非ゼロ成分をメモリ上に保存する、非ゼロソルバー。次に、係数行列の全体化は行わず、要素剛性行列の形でメモリ上に保存する、EBE ソルバー。最後に、要素剛性行列すらメモリ上に保存せず、行列ベクトル積が必要とされる都度に評価す
る EBE-MSF(Matrix Storage-Free)ソルバー。以下、係数行列を対称とし、CG ソルバーにおいてこの３種類のソルバー実装の性能見積もりを行う。なお、行列ベクトル積部分の並列化は比較的容易であり、通信パターンは隣接間が主なものとなる。

65 / 253

非ゼロソルバーの場合、全体剛性行列とベクトルとの積であることから、メモリアクセ
スは主に行列成分のみとなる。行列の 1 成分をメモリから読み出すごとに、対称性を考慮して 4 個の浮動小数点演算が必要となる。ただし、行列は疎でしかも非構造格子からのものであるため、メモリアクセスは不規則でベクトル化の効率は低く、しばしば節点単位でのレジスタブロッキングが不可欠となる。またギャザー・スキャッタ機構は性能向上に役立つ。
次に EBE ソルバーの場合、メモリ上に記憶された個々の要素剛性行列とベクトルとの積結果を組み上げていくことになる。要素剛性行列は密で対称であるため、非ゼロソルバーと同様、行列の 1 成分ごとに 4 個の浮動小数点演算が必要となる。EBE ソルバーは非ゼロ
ソルバーより記憶量、演算量とも多いが、メモリアクセスパターンは比較的規則的で性能が出しやすい。
最後に、EBE-MSF ソルバーの場合、これは陽解法ソルバーの場合と同様、EBE 演算がメインとなる。B/F 値の低い計算機でも有効である。もし B/F 値が極端に低い場合、本ソルバーは主にメッシュデータのみをメモリから読み出すため省メモリであり、しかも他のソルバーよりメモリアクセス量が少なくなるために結果的に最速ソルバーとなる可能性がある。
続いて、領域分割法について述べる。先に述べた線形代数レベルでの並列化を行った並列反復法ソルバーと異なり、領域分割法（Domain Decomposition Method: DDM）は偏微
分方程式レベルでの並列化手法である。まず全体領域を複数の部分領域に分割する。各部
分領域に適当な境界条件を与えて独立に解き、領域間境界条件が落ち着いてくるまで反復的にこれを繰り返す。したがってこの方法は反復解法の一種である。構造問題においては、
並列反復法ソルバーの場合と同様、強力な前処理が不可欠となる。DDM の場合、FETI や
BDD などのマルチグリッド型前処理が多用されている。
DDM の主要な演算パターンは部分領域ごとの有限要素解析（ローカルソルバー）である。
DDM の並列化はローカルソルバーを単位として、その並列化は容易であり、通信パターン
は隣接間がメインとなる。
部分領域ローカルソルバー実装にはいくつかの方法が考えられる。まず一つ目は、部分
領域ごとの剛性行列について、これをまず直接法ソルバーを用いて行列分解し、スカイラ
イン形式などでメモリ上に保存しておく。DDM 反復ごとに前進後退代入を行う。
2 つ目は、
部分領域ごとに反復法ソルバーを用いて部分領域問題を解く。このとき、メモリ上にはほとんどデータを記憶しない。3 つ目は、部分領域ごとに対応する密行列をあらかじめ作成しておき、これらとベクトルとの積を繰り返す。これは並列反復法ソルバーにおける EBE ソ
ルバーのように、ローカル Schur 補元行列と呼ばれる、部分領域ごとの剛性行列を静的縮約により陽に導出してメモリ上に保存しておくものである。
最初の直接法ソルバーアプローチでは、行列分解されたデータに対する前進後退代入演算が主である。この場合、行列の 1 成分を読み出すごとに 2 個の浮動小数点演算が必要と66 / 253

なる。
2 つ目の反復法ソルバーアプローチでは、メモリからメッシュ情報を読んでキャッシュ上で反復法ソルバーを起動する。大量の演算が L2 あるいはラストレベルキャッシュ上で行われることになる。並列反復法ソルバーで説明した非ゼロ、EBE、あるいは EBE-MSF ソル
バーどれも利用可能である。なお、前処理の導入により反復回数を削減したい場合、前処
理行列をあらかじめ作成してメモリ上にストアしておくことも考えられる。
最後のローカル Schur 補元行列保存の場合、EBE ソルバーと同様、対称な密行列とベクトルの積であり、1 成分ごとに 4 浮動小数点演算を要する。なお、部分領域ごとに静的縮約によりローカル Schur 補元行列を作成する際に、行列行列積を中心とした大量の浮動小数
点演算が行われる。
2.4.3 連続体力学分野向け DSL のための行列、テンソル操作ライブラリ：AutoMT
上記の例でみられたように、有限要素法にもとづくシミュレーションでは要素を単位として手法が組み上げられているため、その計算パターンにおいても頻繁に要素単位の計算が求められる。ここでとりあげられる AutoMT（「おてもと」）ライブラリは、シミュレー
ションコードにおいて大量に実行される有限要素単位での小規模演算、特に小規模行列およびベクトル、あるいは二次元／三次元テンソルに関する演算パターンを高速化する。本
ベンチマークでは、AutoMT ライブラリにおける小規模行列およびテンソル演算の性能ベ
ンチマークテストを行った。
2.4.4 低レベル線形代数ソルバーライブラリ：AutoLinAS
一方、LexADV フレームワークにおける HDDM ライブラリは大規模な全体システムレベルでの連立一次方程式を並列環境において階層型領域分割法を用いて解くためのものである。前述したように、ここには部分領域ごとのローカルソルバーが含まれ、この部分の性能特性は領域分割法コードの性能を全般的に支配するものとなる。そこで、部分領域ローカルソルバーにおいて必要となる、シングルコアあるいはシングル計算ノード・ノード
内 OpenMP 並列に対応する中規模連立一次方程式の解法を高速化するための低レベルイン
ターフェイスが新たに求められる。AutoLinAS（「おとりなし」）はこのための線形代数ソルバーライブラリとなっている。これは、直接法としてスカイラインソルバー、反復法として CG ソルバーについて、それぞれプラットフォームごとに性能最適化された実装を有する。本ベンチマークでは、そのうち主に CG ソルバーにおける計算カーネルとなる、非ゼロ成分より構成されるスパース行列とベクトルとの積（SpMV）の性能ベンチマークテストを行った。

67 / 253

連続体力学向けドメイン特化言語AutoMT（ＦＸ１０でのベンチマーク）

河合浩志（諏訪東京理科大）

背景• より複雑な物理現象、より高度な数値スキーム

 要素開発作業がたいへんに– 連成解析、大歪弾塑性、異方性シェル、破壊、乱流– コンシステント接線剛性、歪仮定要素、メッシュフリー、均質化法• HPC向けプロセッサの高速化– 数値計算向け命令セット拡張• SIMD命令（マルチメディア拡張命令）– SSE, AVX (インテル/ AMD), HPC-ACE (富士通), NEON (ARM)– メニーコアやGPGPUなど

大量のテンソル式（または行列・ベクトル演算）の嵐 ！！！
68 / 253

連続体力学向けDSL• ドメイン特化言語 DSL（Domain Specific Language)– 問題分野向け専用言語– 特定の問題分野（数学、量子力学、図形処理、経済学など）向けに特化したプログラミング言語• Matlab, Mathematica• 各アプリケーションが有するマクロ・スクリプト– 問題分野の語彙を直接用いる• システムの高レベル設計に有効• ユーザーとの対話や要求仕様設定に有効• トランスレータによりFortran、C、Javaなどコードを自動生成• 計算力学分野、特に連続体力学(Continuum Mechanics)向けに特化した計算機言語？
– 行列・ベクトル演算– テンソル演算

連続体力学DSL： 数式からコード自動生成
テンソル形式で記述
tr 

tr 

 etr

 etr

行列・ベクトル形式で記述

C  2GQ σ  σ  2GRI  ( K  2 GR)I  I
ep

3[ D ep ]  [ D e ] 

Fortranコード3G

 e 2 (1 h)3G{ }{ }T(ライブラリサブルーチンをコール）

C言語コードreal*8 G, K, Q, R, sigma_tr_e
real*8 st_sigma_tr_prime(6), st_I(6)real*8 mnst4_I(6,6), mnst4_II(6,6), mnst4_C_ep(6,6)
call automt_otimes_st_st_mnst4(st_sigma_tr_prime, st_sigma_tr_prime,
mnst4_tmp1)
call automt_prod_s_mnst4_mnst4(2.0d0 * G * Q / sigma_tr_e, mnst4_tmp1,
mnst4_tmp1)
call automt_prod_s_mnst4_mnst4(2.0d0 * G * R, mnst4_I, mnst4_tmp2)
call automt_add_mnst4_mnst4_mnst4(mnst4_tmp1, mnst4_tmp2, mnst4_tmp1)
call automt_prod_s_mnst4_mnst4(K – 2.0d0 / 3.0d0 * G * R, mnst4_II, mnst4_tmp2)
call automt_add_mnst4_mnst4_mnst4(mnst4_tmp1, mnst4_tmp2, mnst4_C_ep)（ライブラリ関数をコール）
double G, h, sigma_e;
double v6_sigma_prime[6];double m6x6_D_e[6][6], m6x6_D_ep[6][6];automt_prod_v6_v6tp_m6x6(v6_sigma_prime, v6_sigma_prime, m6x6_tmp1);
s_tmp1 = (3.0 * G) / (sigma_e*sigma_e* (1.0 + h / (3.0 * G)));
automt_prod_s_m6x6_m6x6(s_tmp1, m6x6_tmp1, m6x6_tmp1);
automt_sub_m6x6_m6x6_m6x6(m6x6_D_e, m6x6_tmp1, m6x6_D_ep);

69 / 253

連続体力学シミュレーション分野向けDSL
解析プログラム・コードの特性
要素・セル・粒子系： 物理モデル

全体システム系： 力学モデル• 物理現象の詳細を記述• テンソルまたは小規模行列• 点上（積分点、セル中心）で評価
 点ごとに独立・並列で キャッシュ上で• 大量の数式 コードの大部分を占める• 近似手法（FEM、FVM、SPH…）• 行列・ベクトル式または差分式• 隣接関係を記述
 大規模な行列 ステンシル演算• 数式の数自体は少ない
 線形代数ソルバー

典型的なシミュレーションコードの構造シミュレーションモデル

物理モデル
計算格子・メッシュと独立なロジック

力学モデル
計算格子・メッシュに依存するロジック

シミュレーションコード

ライブラリ
関数呼び出し物理モデル
部分のコードσ ＝ C ε + ε。

テンソルと（小サイズな）行列
演算ライブラリ

力学モデル
部分のコード[K] {u} = {f}ライブラリ
関数呼び出し大規模線形代数ソルバー
ライブラリ[A] {x} = {b}70 / 253

連続体力学向けDSLシステム構成
DSL
スクリプト

要素、セル、粒子単位での計算コード

数式

テンソルまたは(小規模）行列演算

ＤＳＬ
トランスレータ（ＬａＴｅＸベースの言語仕様）

AutoMT（おてもと）
特定アーキテクチャ向け
性能最適化

Intel系向け実装

テンソル演算、行列ベク
トル演算向けライブラリ
CUDAによる実装

京、FX10系向け実装

その他…

MIC向け実装（例） 超弾性neo-Hookean材^C  2  III C

1 / 3

[

1
1
1
1
ICI 
I  C 1 C 1  I 
I C C 1  C 1 ]3
3
3
9

LaTeXコード{¥bf ¥hat{C}} =2 ¥mu III_C^{-1/3}[1/3 I_C {¥bf I} - 1/3 I ¥otimes C^{-1} - 1/3 C^{-1} ¥otimes I + 1/9 I_C C^{-1} ¥otimes C^{-1}]

Ｃコード
tmp0 = 2.000000 * mu;
tmp1 = 1.000000 / 3.000000;
tmp2 = -tmp1;
tmp3 = pow (III_C, tmp2);
tmp4 = tmp0 * tmp3;
tmp5 = 1.000000 / 3.000000;
tmp6 = tmp5 * I_C;
AutoMT_prod_s_t4_t4 (tmp6, T4_I, tmp7);
tmp8 = 1.000000 / 3.000000;
AutoMT_prod_s_t_t (tmp8, T_I, tmp9);
AutoMT_inverse_t_t (T_C, tmp10);
AutoMT_otimes_t_t_t4 (tmp9, tmp10, tmp11);
AutoMT_sub_t4_t4_t4 (tmp7, tmp11, tmp12);

tmp13 = 1.000000 / 3.000000;
AutoMT_inverse_t_t (T_C, tmp14);
AutoMT_prod_s_t_t (tmp13, tmp14, tmp15);
AutoMT_otimes_t_t_t4 (tmp15, T_I, tmp16);
AutoMT_sub_t4_t4_t4 (tmp12, tmp16, tmp17);
tmp18 = 1.000000 / 9.000000;
tmp19 = tmp18 * I_C;
AutoMT_inverse_t_t (T_C, tmp20);
AutoMT_prod_s_t_t (tmp19, tmp20, tmp21);
AutoMT_inverse_t_t (T_C, tmp22);
AutoMT_otimes_t_t_t4 (tmp21, tmp22, tmp23);
AutoMT_add_t4_t4_t4 (tmp17, tmp23, tmp24);
AutoMT_prod_s_t4_t4 (tmp4, tmp24, T4_C_hat);

１行の数式（２行のLaTeXコード）から２６行のＣコードに変換
71 / 253テンソル演算および行列ベクトル演算のためのライブラリ
AutoMT「おてもと」 in ADVENTURE Auto
いまより楽にコードを書きたい
行列・テンソル演算を多用する
プログラミング作業の効率化・省労力化

ま、できれば、コードが速いに越したことはない
現在および将来のプロセッサ上で高速に動作するようなライブラリ実装・コード生成

テンソル演算からコードへのマッピング
ベクトルテンソル積、ベクトル同士のドット積
a X・ｂdouble a[3];double X[3][3];double b[3];double s;
double tmp[3];automt_prod, automt_cdotaXbs = a X・ｂ

automt_prod_t_v_v (a, X, tmp);
automt cdot_v_v_s (tmp, b, s);

72 / 253

入力 : a, X
出力 : tmp
入力 : tmp, b
出力 : sマッピング例
演算からFortranサブルーチンコール（C関数）へのマッピング
X+Y

automt_add_t_t_t

Xa

automt_prod_t_v_v

XY

automt_prod_t_t_t

X ：Y

automt_colon_t_t_s

X ・・Y

automt_dotdot_t_t_s

det X

automt_det_t_s

X-1

automt_inv_t_t

サポートされている演算 (1)ベクトル演算<単項演算><二項演算>

|a|

a+b

a-b

sa

a・b

a×b

a b

<３項演算>[a b c]a, b, c : ベクトルs, t : スカラー73 / 253サポートされている演算 (2)２階テンソル演算<単項演算>
tr X

det X
XT

<二項演算>X -1

X -T<複雑な演算>

X+Y

X-Y

sX

XY

X ：Y

X ・・Y

Xa

aX

対称部・非対称部への分解
各種不変量
固有値、固有ベクトル
座標変換
X n (n:実数)
極分解

X,Y : ２階テンソルa, b, c : ベクトルs, t : スカラー

サポートされている演算 (3)４階テンソル<２項演算><単項演算>
A-1<他の演算>

A +B

A-B

A：X

X：A

sA

座標変換
行列形式への変換<定数>O
I

A, B, C: ４階テンソル
X,Y : ２階テンソルa, b, c : ベクトルs, t : スカラー

I I

74 / 253

対称性
Xaautomt_prod_st_v_v

real*8 X(6)real*8 a(3)real*8 b(3)X (２階の対称テンソル)ab=XaX(1)=X11
X(2)=X22
X(3)=X33
X(4)=X12
X(5)=X23
X(6)=X31
call automt_prod_st_v_v (X, a, b)

入力 : X, a
出力: b

４階テンソルの対称性
6

9

6

6
6

9

Minor symmetry
6x6
Major symmetry
upper triangle only
(21成分)

Minor symmetry
6x6No-major symmetry(36成分)

No-minor symmetry
9x9No-major symmetry(81成分)

real*8 C(21)real*8real*8C(6,6)

75 / 253

C(3,3,3,3)

転置
転置演算は、実際には浮動小数点演算を行わない
他の演算と組み合わせる
X Ta

automt_prod_ttp_v_v

X YT

automt_prod_t_ttp_v（例） 弾塑性、Ｊ２則、等方硬化C  2GQ
ep

σ tr 

tr

e

σ tr 

2
2
(

GR
I

K

GR )I  Itr3
e

real*8 G, K, Q, R, sigma_tr_e
real*8 st_sigma_tr_prime(6), st_I(6)real*8 mnst4_I(6,6), mnst4_II(6,6), mnst4_C_ep(6,6)
call automt_otimes_st_st_mnst4(st_sigma_tr_prime, st_sigma_tr_prime, mnst4_tmp1)
call automt_prod_s_mnst4_mnst4(2.0d0 * G * Q / sigma_tr_e, mnst4_tmp1, mnst4_tmp1)
call automt_prod_s_mnst4_mnst4 (2.0d0 * G * R, mnst4_I, mnst4_tmp2)
call automt_add_mnst4_mnst4_mnst4 (mnst4_tmp1, mnst4_tmp2, mnst4_tmp1)
call automt_prod_s_mnst4_mnst4(K – 2.0d0 / 3.0d0 * G * R, mnst4_II, mnst4_tmp2)
call automt_add_mnst4_mnst4_mnst4 (mnst4_tmp1, mnst4_tmp2, mnst4_C_ep)
76 / 253

問題提起• スパコン： ペタからエクサへ– 分散メモリ並列で数千～数万ノード  今後も増える？
• 電力制約 （発電所が必要？？？）– （では、）計算ノード(~=PC,WS)あたりの性能が向上？

• PC、WS： ギガからテラへ– 現在の状況• Intel Core i7 3.4 GHz、６コア

3.4 x 8 x 6 = 163 GFLOPS• Intel Xeon Phi (Knights Corner) 、６０コア• GeForce GTX Titan (Kepler)

1.0+ TFLOPS
1.0+ TFLOPS

 １０X ～ １００X の性能向上？？？

– クロック周波数は伸び悩み （１～３GHｚ）– メモリバンド幅ボトルネック

問題提起 (2)• 目の前のマシンでの性能乖離– 誰かさんのコードは10 T FLOPSで動作• 自分のコードでは1 G FLOPSしか。。。
– １万倍の格差！！！

– 何が違う？
• アクセラレータ利用• 専用言語(CUDA)、ディレクティブ（OpenMP、OpenACC)、ライブラリ• 並列化 ＋ α
– キャッシュ、SIMD命令拡張、ソフトウェアパイプライン、。。。

• 何が問題なのか？
– 並列化する （マルチコア、メニーコア）– キャッシュに載せる （メモリバンド幅制約からの解放）– アーキテクチャをうまく使う （理論ピーク性能を目指す）
77 / 253コード最適化
HPC業界における重要課題（実アプリにおける）ピーク性能比向上＋(ノード内）単体性能

ノード間並列化

マルチコア／メニーコア化により、相対的にメモリが遅くなっているので… (Memory Wall)
メモリの壁

キャッシュに載せる！
キャッシュに載っていても…

キャッシュ上で性能が出ない！！！
Compiler Wall ???
コンパイラの壁

単体性能の向上： 最新スカラー機事情
１００％（LINPACK）
アセンブリ言語
ベンダーライブラリ（BLASなど）

ピーク
５０％
性能比

メモリの壁
SIMDベクトル化
アンローリング

３０％ 連続メモリ
１０％ アクセス
５％キャッシュの有効利用

易しい

ピークの１割を狙う？

コンパイラの壁
厳しい

実装の難易度IF キャッシュに載る

並列性能の確保＋命令実行効率の向上

ELSE （メモリバンド幅ネック）

並列性能の確保 （だけしか。。。）
78 / 253

オンキャッシュなのに性能がでない？
キャッシュに載っていても…

キャッシュ上で性能が出ない！！！
Compiler Wall ???

正確には…

ILP (Instruction-Level Parallelism) Wall
命令レベルの並列性に問題あり

1クロックに何個の演算を並列実行できるか？
スーパー
スカラー

積和命令
（FMA)

SIMD
命令

計

2
2
2
2
2

2
2
1
2
1

2
2
4
4
8

8
8
8
16
16

京(富士通SPARC64
VIIIfx)IBM Power7
Sandy Bridge
Haswell
Knights Corner

1クロックに複数命令同時実行するには？
• スーパースカラ、FMA： 積と和の同時実行– 積の数と、和（差）の数のバランスが必要– 除算、ルート、sin、logなどは対象外• SIMD： 複数データに対する同一種類演算の一括処理– 演算パターンの規則性が重要• 配列とループ ： ショートベクトル化• ループボディ内の大量の演算からペアリング（UXSIMD)• メモリアクセス– （ほとんど）レジスタに載っていることが重要– 配列へのシーケンシャルアクセスが望ましい

NINJAギャップ（by Intel)の発生
79 / 253

さて、実際のコードは？
• １重ループ （ループ長が長い）

キャッシュ 悪命令数 少– ボディが小さい

×– ボディが大きい◎ レジスタ 良

数行程度

キャッシュ 良数十～数百行

命令数 多• 多重ループ （ボディが小さい）– 内側ループ長が長い

キャッシュ 良○ レジスタ 良
命令数 増やせる

数十～数百– 内側ループ長が短い
１０以下△

キャッシュ 良レジスタ 悪命令数 増やせない

コード最適化の例 （行列ベクトル積）ー 従来型のスカラー向け ー
通常のコードdouble a[3][3];double b[3];double c[3];for (i = 0; i < 3; i++) {c[i] = 0.0;
for (j = 0; j < 3; j++) {c[i] += a[i][j] * b[j];
}
}

•
•
•

最適化されたコード
double a_0_0, a_0_1, a_0_2;
double a_1_0, a_1_1, a_1_2;
double a_2_0, a_2_1, a_2_2;
double b_0, b_1, b_2;
double c_0, c_1, c_2;
c_0 = a_0_0 * b_0 + a_0_1 * b_1 + a_0_2 * b_2;
c_1 = a_1_0 * b_0 + a_1_1 * b_1 + a_1_2 * b_2;
c_2 = a_2_0 * b_0 + a_2_1 * b_1 + a_2_2 * b_2;

短いループ  ループ展開 （ループのフル・アンロール）
短い配列  スカラー変数に関数コール  マクロに （関数インライン展開）
80 / 253コード最適化の例（続）ー SIMD強化されたスカラー向け ー
ショートベクトル化されたコード
double a_0_0[4], a_0_1[4], a_0_2[4];double a_1_0[4], a_1_1[4], a_1_2[4];double a_2_0[4], a_2_1[4], a_2_2[4];double b_0[4], b_1[4], b_2[4];double c_0[4], c_1[4], c_2[4];For (k = 0; k < 4; k++) {c_0[k] = a_0_0 [k] * b_0 [k] + a_0_1 [k] * b_1 [k] + a_0_2 [k] * b_2 [k];c_1[k] = a_1_0 [k] * b_0 [k] + a_1_1 [k] * b_1 [k] + a_1_2 [k] * b_2 [k];c_2[k] = a_2_0 [k] * b_0 [k] + a_2_1 [k] * b_1 [k] + a_2_2 [k] * b_2 [k];}•ショートベクトル化のための人工的なループを追加
４，８，１６（…)個ごとに並列実行

コードチューニングのガイドライン• 関数呼び出しをマクロに– 明示的にインライン展開• 配列を使わず、（大量の）スカラー変数で代用– 明示的にループアンローリング• 複数の要素について同時処理– 要素数方向にベクトル化・SIMD化– ループを明示的に記述• ループにコンパイラディレクティブを適宜挿入– 最適ループ長はHWアーキ依存• x86系では４、８、１６あたり• 京・FX10ではベクトル長を数十程度に（例：４８、７２、９６）– ベクトル化・SIMD化できない部分を分離して別ループに• 配列への間接インデックス参照• 分岐
81 / 253

例： 構造解析のホットスポット• 要素単位の演算– 要素剛性行列の評価• 数値積分（各積分点で[B]t[D][B]を評価）• 面積・体積積分公式の利用 （三角形と四面体の場合）– 非線形構造解析• 材料構成則の扱い （[D]マトリクス、C ４階テンソル）• 応力積分

– 陽解法系コード– Element-by-element行列無記憶型反復法ソルバー
多重ループ
外側ループ長い
内側ループ短い行列またはテンソル演算

対策

6

3

△

キャッシュ 良レジスタ 悪命令数 増やせない

63[B]t 6 [D] 6 [B]for i = 0～2
for j = 0～5
for k = 0～2
BtDB[i][j] = …

（行列・テンソルライブラリの）マクロによる実装、インライン展開

配列変数からスカラー変数へ 行列・テンソル演算の短ループのフルアンロール
キャッシュ 良◎ レジスタ 良
命令数 多
82 / 253

主要パターンを網羅
BtDB_0_0=…
BtDB_0_1=…
BtDB_0_2=…
BtDB_1_0=…
BtDB_1_1=…

有限要素法向けベンチマークテスト
Intel (Sandy Bridge)

東大Oakleaf-FX

インテルコンパイラ

オリジナル チューニング オリジナル チューニング

構造解析・要素剛性

22%

70%

2%

44%

非線形材料構成則

12%

31%

10%

40%

熱伝導解析・要素剛性

24%

50%

12%

38%

Intel系 Cコンパイラ、-O3 –xAVX
ショートベクトル化によるSIMD命令生成

最適ベクトル長＝４FX10(および京） Cコンパイラ、-Kfast （＋ディレクティブ）
VSIMDによるSIMD化
最適ベクトル長＝２～８０

83 / 253

LexADV-AutoMTおよびAutoLinAS（FX100でのベンチマーク）

河合浩志（諏訪東京理科大）

1

ADVENTURE : Open-source CAE package
Module-based Architecture : 20+ modules
CAD-connection, Mesh Generation,
Domain Decomposition, FE-Solvers,
Visualization, Optimization, etc.
AdvIO, AdvTriPatch, AdvTetMesh,
AdvBCtool, AdvSolid, AdvVisual,
AdvCAD, AdvThermal,
AdvMagnetic, AdvForge,
AdvImpact, AdvFluid, AdvIAgent,
AdvOpt, AdvShape, AdvMaterial,
AdvAuto,http://adventure.sys.t.u-tokyo.ac.jp/

It’s open-source ! 2
84 / 253

大規模問題の並列化• （反復法で）行列ベクトル積などを並列化ex.) 並列ＣＧソルバー
前処理: ブロックIC, 近似逆行列、AMG, ...
特徴： 全体行列を扱う [A]{x}={b}• 領域分割法 (反復型サブストラクチャ法）
ex.) DDM
前処理: BDD, FETI, ...
特徴: インターフェイス問題（Schur補元行列）を扱う[S]{u}={g}3領域分割法（ＤＤＭ）のフロー
領域間境界でのディリクレ境界条件

FEM FEM FEM

FEM

領域間境界でのフラックス・反力

収束判定

終了

領域間境界条件の更新
485 / 253

部分領域ローカルＦＥソルバー-- 部分領域自由度と計算コストの関係 -計算時間

直接法
計算型

直接法
記憶型

キャッシュ
あふれ

N5/3
N7/3

反復法
N4/3

直接法
LSC
N4/3
部分領域の
自由度数
500 1000

10000

3000

5
N

反復法ベースのローカルＦＥソルバーの可能性？
• ポイント– 計算量がN4/3に比例– キャッシュに入れられる（？）– SSOR前処理(+Eisenstat技法)は効率的• 議論– 部分領域が大きくなるとキャッシュに入らない• 並列化が必要  前処理の並列化はどうする？

– キャッシュ上での実行効率（ピーク性能比）が低い！！！
• 間接インデックス参照、scatter/gatherの多用• 無理にキャッシュに入れず、メモリから読んでも同じ？？？
86 / 253

6

ＤＤＭに基づくコードのモジュール構成
システム全体を記述する
行列方程式

要素・セル・粒子
単位計算

ＨＤＤＭ
ライブラリ

テンソルまたは(小規模）行列演算（大規模）線形代数
ソルバーライブラリ

AutoMT「おてもと」(小規模）行列・
テンソル
ライブラリ

AutoLinAS「おとりなし」特定アーキ
テクチャ向け
性能最適化（中規模）線形代数
ソルバーライブラリ7

線形代数ソルバーライブラリ AutoLinAS• 直接法ソルバー– 対称行列向け： [L][L]^T、[L][D][L]^T– フル、スカイライン– プラットフォームごとの最適化およびスレッド並列化• 反復法ソルバー– 対称行列向け： CG法– 前処理： 対角スケーリング、SSOR、ICT– プラットフォームごとの最適化およびスレッド並列化• ツール– 疎行列用インデックス管理、リナンバリング– ４倍精度(double-double)
8

87 / 253

反復法ソルバーの記憶形式

ＥＬＬＰＡＣＫ
形式

非ゼロ成分のみ
バンド

バンド

ＦＥＭでの疎行列

非ゼロ成分のみ記憶する（CRS形式)
9

節点ブロック化ABC（二次元）三角形一次要素

A

1

B

1

C

2

2

3

3
全体剛性行列へのアセンブル

要素剛性行列10
構造問題：三次元ソリッド要素では３ｘ３節点ブロック
88 / 253

SIMD拡張命令• 複数命令を同時実行する仕組み（ＩＰＣの向上）– 同一の演算命令を複数のデータに適用（ＳＩＭＤ）– レジスタサイズを拡大（２５６ビットであればdouble4個分）• コンパイラによる支援 （ＳＩＭＤベクトル化）– “いわゆる”ベクトル化可能なループを対象– （現在は）配列へのシーケンシャルアクセスのみ• gather/scatter命令のサポートは？？？

例) c[i] = a[i] × b[i]
レジスタ0

a[0]

a[1]

a[2]

a[3]

レジスタ1

×
b[0]

×
b[1]

×
b[2]

×
b[3]

レジスタ2

||
c[0]

||
c[1]

||
c[2]

||
c[3]

11

疎行列ベクトル積(SpMV)ベンチマーク• チューニング対象– x86アーキテクチャ• Intel Core i7 / Xeon (Haswell)• Intel Xeon Phi (Knights Corners)– 富士通 （京、FX10、FX100）• 実装手法– 節点ブロック化(3x3)、対称性の利用– ELLPACK形式 （行あたりの成分数を固定）– 節点ブロック単位SIMDベクトル化– 列方向SIMDベクトル化
12

89 / 253

ベンチマーク詳細 (1)• 基本方針– Ｃ言語を使用– コンパイラの最適化機能に頼る• Intelコンパイラおよび富士通コンパイラ– ＳＩＭＤベクトル化• アセンブリ言語やintrinsic関数は使わない– 動的メモリ確保(malloc)• 静的確保の場合に対し、性能が低下しないか？

– １部分領域を１スレッドで解く• 部分領域数に関してOpenMP並列化• 部分領域データがコアごとのキャッシュに載るか？ 13

ベンチマーク詳細 (2)• 富士通FX100 (SPARC64 XI 2.2GHz, 32 core)– Ｂ／Ｆ値0.426（readはその半分）、4-way SIMD、キャッシュ0.75MB / core
– オプション：-Kfast –Kocl– ディレクティブ： novrec、swp、simd• Intel Xeon E3-1270, 3.5 GHz, 4 core (Haswell)– Ｂ／Ｆ値0.114、4-way SIMD、キャッシュ 2MB / core
– オプション: -O3 –xCORE-AVX2– ディレクティブ： ivdepおよびsimd• Intel Xeon Phi 5110P, 1.05GHz, 60 core (Knights Corner)– Ｂ／Ｆ値0.317、8-way SIMD、キャッシュ0.5MB / core
– オプション： -O3 -mmic– ディレクティブ： ivdepおよびsimd
90 / 25314疎行列ベクトル積ベンチマーク

FX100

14 – 11 %(7 %)キャッシュに載らない
8.4 – 8.1 %(6.7 – 6.3 %)Haswell

16 – 14 %8.2 %Knights Corner

5.7 – 3 %4.8 – 3.2 %オンキャッシュ注意1： （多くの場合）最大値はELLPACK、最小値はCRS
注意2： ()内は動的メモリ確保(malloc)を行った場合

SIMDがほとんど効いていない？？？

15

考察（１）
• 3x3節点ブロックは確かに効く• 対称性を考慮した方がよいことが多い– キャッシュに載らない場合は特に– 場合により、一般行列でもそこそこ高速なことがある– とりあえず、メモリ使用量は半分で済む• ELLPACK vs. CRS– ELLPACKは命令実行効率は良いが、演算量が多い• 要素タイプやメッシュごとに調整が必要• ＣＲＳ含め複数の記憶タイプを組み合わせる必要– 実装が複雑に

16

91 / 253

考察（２）• Xeon Phi： キャッシュの効果は？
– 二次キャッシュ容量： コア当たり512KB– ６０コアに対し、１２０または２４０スレッドが最適• コアごとに２～４スレッドを実行– スレッドごとに１部分領域を扱う• 部分領域ごとに使えるキャッシュはきわめて少なくなる• FX100： mallocすると遅くなる？？？
– プラグマnovrec、swp、simd alignedを使用– オンキャッシュ状態での性能劣化が著しい

17

考察（３）
• SIMDは本当に効いているのか？
– 本当にＳＩＭＤ化されているのか？
• gather / scatter命令が使われているのか？
• 生成されたアセンブリ命令の確認が必要– たとえgather/scatterを使っていたとしても• それで本当に速くなるのか？

18

92 / 253単体性能の向上： 最新スカラー機事情
１００％（LINPACK）
アセンブリ言語
ベンダーライブラリ（BLASなど）

ピーク
５０％
性能比

メモリの壁
SIMDベクトル化
アンローリング

３０％ 連続メモリ
１０％ アクセス
５％

コンパイラの壁

キャッシュの有効利用

易しい

厳しい

実装の難易度コンパイラの壁 ???

19

オンキャッシュなのに性能がでない？
キャッシュに載っていても…

キャッシュ上で性能が出ない！！！
Compiler Wall ???

正確には…

ILP (Instruction-Level Parallelism) Wall
命令レベルの並列性に問題あり

1クロックに何個の演算を並列実行できるか？

京(富士通SPARC64
VIIIfx)
富士通FX100
Haswell
Knights Corner

スーパー
スカラー

積和命令
（FMA)

SIMD
命令

計

2
2
2
2

2
2
2
1

2
4
4
8

8
16
16
16 20

93 / 2532.5 LAMMPS/ReaxFFのFX100における性能評価とチューニング
株式会社豊田中央研究所
平井 宏俊

2.5.1 はじめに
LAMMPS（Large-scale Atomic/Molecular Massively Parallel Simulator ）[1]はアメリカのSandia 国立研究所が中心になって開発を進めているオープンソース（GPL）の古典分子動力学計算パッケージである。LAMMPS は原子、粗視化粒子、有機分子、プロテイン、DNA、金属、グラニュラーなどが取り扱える汎用分子動力学
シミュレータとなっており、様々な種類の力場が取り扱える。ここでは化学反応が取り扱える多体ポテンシャルReaxFF [2] に着目し、スーパーコンピュータFujitsu

PRIMEHPC FX100 での性能評価ならびにチューニングを試みた結果について報告する。

2.5.2 プログラム概要
2.5.2.1 LAMMPS
シミュレーション領域の空間分割を用いたMPI 並列による並列化プログラムとなっている。プログラミング言語にはC++が用いられており、機能はモジュール方式で基本的にソースとヘッダファイルのみで構成されている。そのため拡張性が高
く、コードの80％がコア部分から拡張された部分となっている。

2.5.2.2 ReaxFF
ReaxFF は、 van Duin 教授らによって開発された反応力場 (Reactive Force
Field) である。ReaxFF は、既存の古典分子動力学プログラムとは異なり、結合の生成と開裂を記述することができる。反応力場のパラメータは量子化学計算のデー
タから決められているために化学反応の高精度な記述を可能にする一方で、その動力学計算は通常の古典分子動力学シミュレーションに匹敵する計算速度を保持しており、触媒反応や燃焼反応など、材料科学分野における分子動力学シミュレーシ
ョンの適用範囲を大幅に広げている。ReaxFF はいわゆるボンドオーダーポテンシ
ャルとなっており、通常の分子力場法に比べて演算数、条件分岐が多い傾向がある。

LAMMPS に実装されているReaxFF にはC++版（reaxc）とFortran 版（reax）があるが、本報ではより高速であるC++版を用いる。

94 / 2532.5.3 手法
一般に、アプリケーションの中で多くの実行時間が費やされている箇所（ホットスポット）を見つけ出して、その部分を高速化すると、大きなチューニング効果を得ることができる。プロファイラを使用すると、実行時間の分布などのチューニン
グ情報を得ることができる。ここでは富士通製のFX100 用のプロファイラを用いてアプリケーションの分析を行った。また、LAMMPS のプログラムが標準で書き出す
各ルーチンのタイマー情報も適宜活用した。

2.5.3.1 測定方法
プロファイラには、チューニング情報をサンプリング方式で収集する基本プロフ
ァイラと、指定した区間のチューニング情報を収集する詳細プロファイラがある。
基本プロファイラは、アプリケーションの実行性能情報の収集および出力を、コマンド（_pp）で実現している。これにより、時間統計情報（経過時間、ユーザCPU 時
間とシステムCPU時間の内訳など）、コスト情報（アプリケーション実行中にサン
プリングを行い、その回数を手続、ループおよび行単位にコストとして出力）、ハ
ードウェアモニタ情報（アプリケーション実行時のプロセッサ動作状況を出力）な
どの情報を出力することができる。一方、詳細プロファイラは、アプリケーションの実行性能情報の収集および出力をコマンド（fapp）で実現している。これにより、
基本情報（測定区間の呼出し回数、および時間情報）、MPI 情報（MPI 関数の実行
回数、メッセージ長、実行時間、および待ち時間の平均値、最大値および最小値）、
ハードウェアモニタ情報（アプリケーション実行時のプロセッサ動作状況）などを出力することができる。各プロファイラには区間指定機能があり、コスト情報を測定する範囲を指定することができる。ソースコード上で測定範囲を指定するには、
コスト情報の測定開始位置と測定終了位置にサブルーチン（fipp_start、fipp_stopなど）を挿入する。C/C++言語の関数を使用する場合は、関数のプロトタイプ宣言
を行う、または、基本プロファイラ区間指定機能のヘッダファイルをインクルードする必要がある。

2.5.3.2 測定環境
本報では名古屋大学情報基盤センターに導入されているスーパーコンピュータ

Fujitsu PRIMEHPC FX100 を用いて性能評価を行った。以下の表に上記システムの構成を示す。

95 / 253図1: 測定環境

2.5.3.3 測定条件
本報では以下に示す条件において性能評価を行った。

MDステップ数が2000 となっている以外は、通常の反応解析でよく用いられる条件になっている。通常は5 千から5 万倍の1000 万から1 億 MDステップの計算になるが、計算量が単純に5千から5万倍になるだけであり、演算の質は変わらない。スケーラビリティ以外の性能評価では1 ノード16 コアを用いた。

96 / 253図2: 評価に用いたユニットセル

2.5.4 結果
2.5.4.1 基本プロファイリングデータ
図3 に基本プロファイリング（fipp コマンド）によって得られたProcedures プ
ロファイルを示す。exp、pow の組込関数のコストが大きいことが分かる。これらの組込関数はインライン展開されておらず、インライン展開することで性能向上する可能性がある。Kfastオプションに含まれるKilfunc オプションでは一部の組込関数がインライン展開されることになっている。全てインライン展開すると逆に実行性能が遅くなる場合があるため、コンパイラは閾値を設定して制御している。今回インライン展開されなかったのは、この閾値を超えていたためと考えられる。そこで全ての組込関数をインライン展開するようコンパイル時にオプション指示し、
上記の閾値を変更した。インライン展開後のProceduresプロファイルを図4 に示した。組込関数のインライン展開後はpow、exp などのコストが消え、トータルのコ
ストは6322 から3652 に、実行時間（Operation）は629.3517 から362.5718 に大幅に削減されており、およそ45％の速度向上を達成した。

97 / 253図3: 基本プロファイリングデータ（Procedures） インライン展開前

図4: 基本プロファイリングデータ（Procedures） インライン展開後
図5 にインライン展開前後の実行時間内訳を示した。ここでPair、Neigh、Comm、

Output、Other はそれぞれ、力場の計算、MPI 通信処理、アウトプット出力処理、その他の処理時間を表している。インライン展開後はPair の実行時間が大幅に短縮されている。これはReaxFF の力場の計算にpow やexp が多く含まれるためである。Comm の実行時間も減っているのが確認できる。この要因は以下のように考えられる。後述の通り、Pair の計算部分にロードインバランスがあり、待ち時間が発生しComm のコストが増えてしまう。Pair の計算時間が減ったことでロードイン
バランスの絶対値が小さくなり、待ち時間も減ったためComm の実行時間が減ったと考えられる。

98 / 253図5: インライン展開前後の実行時間内訳

2.5.4.2 ロードインバランス
全体の中で最もコストが大きい力場の計算部分（Pair）をさらに高速化することで、大幅な速度向上が望める。そこで力場の計算部分を担う関数

force->pair->compute() について実行時間をプロセス毎にまとめた。結果を図6に示す。プロセス番号は実際のものではなく、実行時間でソートしている。プロセ
スごとに実行時間が大きく異なっており、ロードインバランスがある。ロードイン
バランスがあると、一部のプロセスに待ち時間が生じるため、実効効率が下がってしまう。ロードインバランスを解消することで速度向上が望める。
LAMMP にはdynamic load-balancing という機能がある（fix balance コマンドで調整可）。この機能を用いると各プロセッサに負荷が均等に分配されるように各プロセッサが担当する粒子数のバランスをとることができる。実際には各プロセッ
サが担当するサブ領域のサイズと形を調整することで各プロセッサが担当する粒子数を変化させている。このバランスをとる作業を分子動力学計算中に定期的（ユーザー設定）に行うことでdynamic なロードバランシングを行うことができる。図7 にdynamic load-balancing による実行時間の変化を示した。1.5 ％程度の速度向上が確認できる。このときのforce->pair->compute()の実行時間をプロセス毎にまとめた結果を図8 に示す。dynamic load-balancing の適用後、ロードインバ
ランスが改善していることが分かる。今回はプロセス数が16 と小さいために、速度向上も僅かであったが、大規模並列計算を実行した際には、ロードインバランス
解消により、大幅な計算効率の向上が見込まれる。

99 / 253図6: 力場の計算部分のプロセス毎の実行時間

図7: dynamic load-balancing の効果

100 / 253

図8: 力場の計算部分のプロセス毎の実行時間(dynamic load-balancing)

2.5.4.3 詳細プロファイリングデータ
ここでは、高コスト関数force->pair->compute() の詳細プロファイリングデー
タ（精密PA）を取得した結果を示す。最初に実行時間の内訳を図9 に示す。浮動小
数点演算待ちが大きいことが分かる。次に、メモリ・キャッシュ・SIMD 情報をまとめた結果を図10 に示す。キャッシュミス率は小さく、メモリ・キャッシュアク
セスについては最適化の余地はないが、SIMD 命令率が極端に小さいのが目立つ。

SIMD 化を促進することで性能向上が見込まれる。本報でコンパイル時に用いているKsimd=2 オプションは、if 文などを含むループも含めてSIMD 拡張命令を利用したオブジェクトを生成するオプションであるはずだが、上手く機能していないようである。そこで、force->pair->compute()内で呼び出されている高コストな関数の例としてボンドオーダーの計算ルーチンであるBO() のソースコードの構造を確認した（図11）。SIMD 化は最内ループに適用されるが、BO() 内のループの最内ループは条件分岐が多く複雑な構造となっている。この複雑な条件分岐のためSIMD化が適用できなかったと考えられる。

101 / 253

図9: 実行時間の内訳

図10: メモリ・キャッシュ・SIMD 情報

102 / 253

図11: ボンドオーダー計算部分のソースコードの構造

2.5.4.4 スケーラビリティ
最後にスケーラビリティを評価した結果を示す。スケーラビリティを評価することにより、ルーチン・関数毎の評価では見えにくい情報（非並列部分がどのくらいあるか？通信時間が大規模並列時にどのくらいの割合を占めるか？ロードインバ
ランスが悪影響しないか？など）を入手することができる。スケーラビリティにはストロングスケーラビリティ（問題規模を一定にし、並列数を増やして評価する）とウィークスケーラビリティ（1 プロセッサ当たりの問題規模を一定にし、並列数を増やして評価する）がある。以下では、それぞれのスケーラビリティについて評価した結果を示す。

2.5.4.4.1 ストロングスケーラビリティ
ストロングスケーラビリティの評価ではこれまでと同様の3600 原子の系について、プロセス数を変化させて評価した。最初に実行時間のプロセス数依存性を示す

103 / 253

（図12）。図中の点線は理想的（実行時間がプロセス数に反比例する）な実行時間の変化を示す。プロセス数の増加と共に単調に実行時間が短縮しているが、プロセス数が大きいところで理想とのズレが大きい。このときの実行時間の内訳を図13に示す。プロセス数の増加と共に通信時間（Comm）の割合が増加している。

図12: 実行時間のプロセス数依存性

図13: 実行時間の内訳のプロセス数依存性

104 / 253

最後に並列化効率（使用したプロセッサの性能をどの位有効利用したか）を図14 に示す。16 並列時には並列化効率が50 ％を下回っている。現在の問題規模（3600 原子）においてはこれ以上プロセス数を増やしても効率が悪い。

図14: 並列化効率

2.5.4.4.2 ウィークスケーラビリティ
ウィークスケーラビリティの評価では450 原子の系（図15）を1 プロセッサ当たりの問題規模として、1 プロセッサ当たりの問題規模を一定にし、並列数を増やして評価した。実行時間のプロセス数依存性を図16 示す。図中の点線は実行時間の理想的な変化（実行時間一定）を示している。なだらかに実行時間が増加しているが、プロセス数が大きいところで変化が小さくなっており、問題規模を64 倍（28800
原子）にしても計算時間の増大は1.6 倍程度に収まっている。実行時間の内訳のプ
ロセス数依存性を図17 示す。通信時間（Comm）の増加は僅かであり、大規模計算時にも通信時間はネックにならないと考えられる。一方、Pair、Other は僅かに上昇している。特にOther はプロセス数と共に単調に増加しており、非並列部が残っている可能性が高い。

105 / 253

図15: 1 プロセッサ当たりの問題規模

図16: 実行時間のプロセス数（問題規模）依存性

106 / 253

図17: 実行時間の内訳のプロセス数（問題規模）依存性

2.5.5 まとめLAMMPS/ReaxFF を対象としてFX100 での性能評価ならびにチューニングを実施した結果、以下の知見を得た。
・組込関数をインライン展開することで大幅に性能向上（計算速度約2 倍）・LAMMPS のdynamic load-balancing 機能を用いることでロードインバランスが改善
・高コストループ内はコールや分岐が多く、SIMD 化が困難
・ウィークスケーラビリティは悪くなく（問題規模を64 倍にしても計算時間の増
大は1.6倍程度）、大規模計算においても性能が出せる

参考文献[1] S. Plimpton, “Fast Parallel Algorithms for Short-Range Molecular Dynamics”,
Journal of Computational Physics, 117, 1-19 (1995).
[2] A. C. Van Duin, S. Dasgupta, F. Lorant, and W. A. Goddard, “Reaxff: a reactive
force field for hydrocarbons”, The Journal of Physical Chemistry A 105, 9396 (2001).
[3] K. Chenoweth, A. C. van Duin, and W. A. Goddard, “Reaxff reactive force field
for molecular dynamics simulations of hydrocarbon oxidation”, The Journal of
Physical Chemistry A 112, 1040 (2008).

107 / 253

2.6 2 次元プラズマ粒子(PIC)コードの測定評価および宇宙プラズマ５次元ブラソフコード
Vlasov5 の測定評価
名古屋大学宇宙地球環境研究所
梅田 隆行

2.6.1 ２次元プラズマ粒子(PIC)コードの測定評価
2.6.1.1 はじめに
Particle-In-Cell（PIC）法 は、1960 年 代 にプラズマ粒 子 と電 磁 場 との相 互 作 用 のシミュレーシ
ョン手 法 として考 案 されて以 来 、様 々な分 野 において幅 広 く用 いられている。オリジナルの PIC 法
は、プラズマ物 理 及 び電 波 科 学 分 野 において開 発 され、格 子 点 （Cell）上 に定 義 された電 磁 場
をマックスウェル方 程 式 により解 き進 め、その電 磁 場 Cell 中 を荷 電 粒 子 が加 減 速 を受 けながら動きまわることから PIC と名 付 けられた。現 実 空 間 に存 在 する膨 大 な数 の荷 電 粒 子 を有 限 の計 算
機 資 源 で扱 うことは不 可 能 であるため、PIC 法 では、ある程 度 まとまった数 の荷 電 粒 子 の集 団 を
1 つの“超 ”粒 子 （super-particle）として扱 っている。PIC 法 では、ラグランジュ変 数 である粒 子 の
位 置 及 び速 度 と、オイラー変 数 である電 磁 場 がデータ配 列 として混 在 しているため、スカラ型 超
並 列 計 算 機 において高 い性 能 を得 るのは容 易 ではない。そのため、様 々なスカラ型 CPU における性 能 特 性 を理 解 しておく必 要 がある。

2.6.1.2 プログラム概 要
プラズマ粒 子 の運 動 は、以 下 の荷 電 粒 子 の運 動 （ニュートン・ローレンツ）方 程 式 によって記 述
される。


drn 
= vn
dt

dv n q n   
E + vn × B
=
mn
dt

(

(1)

)

(2)

また電磁場の時空間発展は以下のマックスウェル方程式によって記述される。


 1 ∂E∇ × B = µ0 J + 2
c ∂t


∂B
∇× E = −
∂t

(3)
(4)

さらに、荷 電 粒 子 が作 る電 流 を計 算 するために、以 下 の電 荷 の連 続 の式 を用 いる。

∂ρ+∇⋅J = 0∂t(5)

運 動 方 程 式 (1) 及 び (2) の 時 間 積 分 が ２ 次 精 度 に な る よ う に 、 粒 子 の 位 置 と 速 度 は 互 い にΔt/2 ずれた時 刻 に定 義 される。また粒 子 の位 置 と電 場 を同 じ時 刻 に、粒 子 の速 度 と磁 場 を同じ時 刻 にすることで、Maxwell 方 程 式 (3)及 び(4)による電 場 の更 新 と磁 場 の更 新 がそれぞれ２次
精 度 になるようにしている。電 磁 場 の各 成 分 （Ex,Ey,Ez,Bx,By,Bz）は、空 間 差 分 が 2 次 精 度 になるように、Yee 格 子 と呼 ばれる Staggered 格 子 上 に定 義 される。また、電 流 密 度 （Jx,Jy,Jz）は電場 （Ex,Ey,Ez）と同 じ空 間 格 子 上 かつ粒 子 の速 度 (磁 場 )と同 じ時 刻 に定 義 される。ラグランジュ

108 / 253

変 数 で あ る 荷 電 粒 子 の 位 置 及 び 速 度 (x,y,z,vx,vy,vz) と 格 子 状 の オ イ ラ ー 変 数 で あ る 電 磁 場（Ex,Ey,Ez,Bx,By,Bz）が混 在 していることが、プラズマ PIC コードの特 徴 と言 える。
プラズマ PIC コードのカーネルは３つに大 きく分 けることができる。１つは Maxwell 方 程 式 (3)及び(4)による電 磁 場 の更 新 で、これには FDTD 法 が用 いられる。電 磁 場 更 新 カーネルの負 荷 が全
体 の計 算 負 荷 で占 める割 合 は 1%未 満 であり、FDTD 法 の性 能 特 性 及 びチューニングについて
は、SS 研 マルチコアクラスタ性 能 WG 成 果 報 告 書 を参 照 して頂 き、ここでは割 愛 する。
2 つ目 のカーネルは、式 (3)による荷 電 粒 子 の速 度 計 算 であり、その概 要 をプログラム１に示 す。
粒 子 がどの格 子 の近 くにあるかを計 算 し(2-3 行 目 )、隣 接 格 子 に対 する重 みを計 算 し(4-13 行
目 )、荷 電 粒 子 の位 置 における電 磁 場 の値 を隣 接 格 子 から重 みに基 づいて計 算 し(14-19 行 目 )、最 後 に荷 電 粒 子 の位 置 における電 磁 場 の値 を用 いて粒 子 を加 速 する(20-22 行 目 )。ここで特 徴
的 なのは、14-19 行 目 が粒 子 の位 置 に対 するリストアクセスになっている点 である。粒 子 番 号 n は
位 置 には全 く依 存 しないため、配 列 のインデックス i,j はランダムとなり、結 果 として 14-19 行 目 の配 列 へのアクセスはランダムロードとなる。
3 つ目 のカーネルは、式 (5)による電 流 密 度 の計 算 であり、その概 要 をプログラム 2 に示 す。粒
子 がどの格 子 の近 くにあるかを計 算 し(2-3 行 目 )、隣 接 格 子 に対 する重 みを計 算 し(4-13 行 目 )、荷 電 粒 子 の位 置 における電 流 を重 みに基 づいて隣 接 格 子 へ割 り振 る(14 行 目 -)。電 流 密 度 計
算 カーネルにも速 度 計 算 カーネルと同 様 に粒 子 の位 置 に対 するリストアクセスが存 在 するが、配列 へのアクセスはランダムロード及 びストアの両 方 となる。また、スレッド間 で同 じインデックスにアクセスする可 能 性 もあるため、配 列 の属 性 は reduction となる。
以 下 では、これら速 度 計 算 カーネルと電 流 密 度 計 算 カーネルの２つについて性 能 測 定 を行 った。
2.6.1.3 測 定 環 境
性 能 測 定 には、名 古 屋 大 学 の旧 システムである FX10 と CX400/250 及 び、新 システムである
FX100 と CX400/2500 を使 用 した。なお、本 測 定 は単 一 ノードで行 い、MPI を用 いた並 列 性 能 の測 定 は行 わない。コンパイラオプションは以 下 のとおりである。


CX250/250（インテルコンパイラ）: –O3 –ipo –ip –xAVX –openmp



CX250/250（富 士 通 コンパイラ）: –Kfast,AVX,openmp



CX250/2550（インテルコンパイラ）: –O3 –ipo –ip –xCORE–AVX2 –openmp



CX250/2550（富 士 通 コンパイラ）: –Kfast,CORE –AVX2,openmp



FX10/FX100（富 士 通 コンパイラ）: –Kfast,visimpact,openmp

2.6.1.4 測 定 結 果
計 算 サイズは 1000x1000 格 子 、144 粒 子 /格 子 とした。これは、約 3GB のメモリ使 用 量 に相 当する。計 算 ステップ数 は 10 とし、スレッド数 を変 える強 スケーリング測 定 を行 った。
図 1 は、名 大 旧 システムにおけるプラズマ PIC コードのスレッド性 能 を示 す。速 度 計 算 カーネルは、富 士 通 コンパイラを用 いた場 合 は高 いスケーラビリティが得 られているが、インテルコンパイラを用 いた場 合 はスレッド数 を増 やすにつれて性 能 が低 下 している様 子 が見 られる。一 方 で電 流
密 度 計 算 カーネルは、富 士 通 コンパイラを用 いた場 合 はスレッド数 を増 やすにつれて性 能 が低下 している様 子 が見 られるが、インテルコンパイラを用 いた場 合 は 4 スレッドまで高 い性 能 を発 揮するものの、4 スレッドで性 能 が飽 和 する様 子 が見 られた。

109 / 253

図 ２は、名 大 新 システムにおけるプラズマ PIC コードのスレッド性 能 を示 す。速 度 計 算 カーネルは、富 士 通 コンパイラを用 いた場 合 はおおむね 70%以 上 でスケールしており、インテルコンパイラを用 いた場 合 は若 干 速 度 が向 上 したものの旧 システムとほぼ同 様 の傾 向 を示 した。電 流 密 度 計
算 カーネルは、富 士 通 コンパイラとインテルコンパイラ共 に旧 システムとほぼ同 様 の傾 向 を示 した。
次 に、粒 子 のデータが完 全 にソートされ、電 磁 場 データへのアクセスが連 続 的 になった場 合 の性 能 測 定 を行 った。図 3 は、名 大 旧 システムにおけるプラズマ PIC コードのスレッド性 能 を示 す。
速 度 計 算 カーネルは、富 士 通 コンパイラを用 いた場 合 は 90%以 上 でスケールしており、インテルコ
ンパイラを用 いた場 合 でも、16 スレッドまでは 90%以 上 でスケールしたが 24 スレッドの時 に性 能 が極 端 に低 下 した。電 流 密 度 計 算 カーネルは、富 士 通 コンパイラを用 いた場 合 は 70%以 上 でスケールしており、インテルコンパイラを用 いた場 合 でも、16 スレッドまでは 90%近 くでスケールしたが16 スレッドの時 に性 能 が飽 和 した。
図 4 は、名 大 新 システムにおけるプラズマ PIC コードのスレッド性 能 を示 す。速 度 計 算 カーネルも電 流 密 度 計 算 カーネルも、富 士 通 コンパイラとインテルコンパイラ共 に旧 システムとほぼ同 様 の傾 向 を示 した。
2.6.1.5 まとめ
本 計 測 で得 られた知 見 は、以 下 のとおりである。
１．富 士 通 コンパイラを用 いた場 合 は、ランダムロードは 70%以 上 でスケールし、連 続 的 なロードは90%以 上 でスケールする。
２．ランダムストアのスレッド性 能 低 下 は、どちらのコンパイラを用 いても、全 てのシステムにおいて顕 著 であり、PIC コードにおけるデータの並 び替 えは性 能 面 からは必 須 である。
３．富 士 通 コンパイラを用 いた場 合 は、連 続 的 なロード及 びストアは 70-80% 以 上 で ス ケ ー ル する。
４．インテルコンパイラを用 いた場 合 は、連 続 的 なロード及 びストアは 90%以 上 でスケールするが、全 コアを用 いた場 合 のみ極 端 に性 能 が低 下 する。
５．シングルスレッドの性 能 は、インテルコンパイラを用 いた場 合 のほうが高 いが、富 士 通 コンパイ
ラを用 いた場 合 ほうがスレッド性 能 が高 いため、結 果 的 にマルチスレッド性 能 は富 士 通 コンパ
イラを用 いた場 合 ほうが高 くなる。
６．FX10 と FX100 は似 た傾 向 を示 す。ランダムロード及 びストアは両 者 で性 能 が数 割 しか変 わら
ないが、連 続 的 なロードは約 3 倍 、連 続 的 なストアは約 1.7 倍 FX100 のほうが高 速 である。
７．IvyBridge と Haswell は傾 向 を示 す。また両 者 で性 能 はほとんど変 わらない。

110 / 253

プログラム１：速度計算カーネル!$OMP DO
1 DO n=1,Np
2

i = nint(x(n))

3j = nint(y(n))

4fx1 = ...

5

fx2 = ...

6

fx3 = ...

7

fy1 = ...

8

fy2 = ...

9

fy3 = ...

10 hx1 = ...
11 hx2 = ...
12 hy1 = ...
13 hy2 = ...

14 pex = ...
15 pey = ey(i-1,j-1)*fx1*hy1 + ey(i,j-1)*fx2*hy1 + ey(i+1,j-1)*fx3*hy1 &+ ey(i-1,j )*fx1*hy2 + ey(i ,j )*fx2*hy2 + ey(i+1,j )*fx3*hy2
16 pez = ...
17 pbx = ...
18 pby = ...
19 pbz = ...

20vx(n) = vx(n) + ...

21

vy(n) = vy(n) + ...

22

vz(n) = vz(n) + ...

23 END DO!$OMP END DO

111 / 253

プログラム 2：電流密度計算カーネル!$OMP DO REDUCTION(+: jx,jy,jz)
1 DO n=1,Np
2

i = nint(x(n))

3j = nint(y(n))

4fx1 = ...

5

fx2 = ...

6

fx3 = ...

7

fy1 = ...

8

fy2 = ...

9

fy3 = ...

10 hx1 = ...
11 hx2 = ...
12 hy1 = ...
13 hy2 = ...

14 jx(i-1,j-1)=jx(i-1,j-1)+q(n)*vx(n)*hx1*fy1
15 jx(i ,j-1)=jx(i ,j-1)+q(n)*vx(n)*hx2*fy1
16 jx(i-1,j )=jx(i-1,j )+q(n)*vx(n)*hx1*fy2
17 jx(i ,j )=jx(i ,j )+q(n)*vx(n)*hx2*fy2
18 jx(i-1,j+1)=jx(i-1,j+1)+q(n)*vx(n)*hx1*fy3
19 jx(i ,j+1)=jx(i ,j+1)+q(n)*vx(n)*hx2*fy3:::
35 END DO!$OMP END DO

112 / 253

図 1： 名 大 旧 シ ス テ ム に お け る プ ラ ズ マ PIC コ ー ド の ス レ ッ ド 性 能 。 ラ ン ダ ム ア ク セ ス の場合

図 2： 名 大 新 シ ス テ ム に お け る プ ラ ズ マ PIC コ ー ド の ス レ ッ ド 性 能 。 ラ ン ダ ム ア ク セ ス の場合

113 / 253

図 3： 名 大 旧 シ ス テ ム に お け る プ ラ ズ マ PIC コ ー ド の ス レ ッ ド 性 能 。 粒 子 デ ー タ を ソ ー ト
した場合

図 4： 名 大 新 シ ス テ ム に お け る プ ラ ズ マ PIC コ ー ド の ス レ ッ ド 性 能 。 粒 子 デ ー タ を ソ ー ト
した場合

114 / 253

2.6.2 宇宙プラズマ５次元ブラソフコード Vlasov5 の測定評価

2.6.2.1 はじめに希 薄 で無 衝 突 状 態 にある宇 宙 プラズマは、磁 気 流 体 力 学 、イオン運 動 論 、電 子 運 動 論 などの様 々な時 空 間 スケールで物 理 現 象 を記 述 できる。Vlasov コードは、宇 宙 プラズマの第 一 原 理
である Vlasov（無 衝 突 Boltzmann）方 程 式 と Maxwell 方 程 式 により、プラズマ中 の全 ての電 磁 ・
静 電 波 動 と荷 電 粒 子 の運 動 との相 互 作 用 を解 くシミュレーション手 法 である。Vlasov 方 程 式 は、
位 置 及 び速 度 の関 数 として表 される位 相 空 間 分 布 関 数 の保 存 則 である。現 実 の世 界 では、位置 及 び速 度 は共 に 3 次 元 であるが、既 存 のコンピュータシステムにおいて 6 次 元 問 題 を扱 うのは困 難 であるため、本 プロジェクトで用 いる Vlasov5 では実 空 間 （位 置 ）を 2 次 元 、速 度 空 間 を 3 次
元 とした 5 次 元 問 題 を扱 う。本 稿 では、前 マルチコアクラスタ性 能 WG 以 降 で行 ったプログラムの改 良 点 についてまとめる。

2.6.2.2 プログラム概 要
Vlasov コードは、Maxwell 方 程 式 による電 磁 場 の更 新 と Vlasov 方 程 式 による分 布 関 数 の更新 から成 る。Maxwell 方 程 式 は電 磁 場 の解 析 で広 く用 いられている FDTD（Finite DifferenceTime Domain）法 により、その時 間 発 展 を解 き進 める。Maxwell 方 程 式 の計 算 負 荷 は Vlasov 方
程 式 の計 算 負 荷 に対 して通 常 0.1%未 満 であるため、今 回 は性 能 評 価 の対 象 外 とした。
Vlasov 方 程 式 による分 布 関 数 の更 新 は、演 算 子 分 離 法 により以 下 のように実 空 間 （位 置 方向 ）の移 流 、電 場 による速 度 空 間 の移 流 及 び磁 場 による速 度 空 間 の回 転 の３つの部 分 に分 解され、それぞれの式 が①実 空 間 の移 流 （position カーネル）、速 度 空 間 の②移 流 （velocity_e カーネル）及 び③回 転 （velocity_b カーネル）に対 応 する。

∂f s  ∂f s+v  = 0∂t∂r∂f s qs  ∂f s+
E  =0∂t ms ∂v
∂f s qs   ∂f s+
(v × B )  = 0
∂t ms
∂v

(1)
(2)
(3)

式 (1)及 び(2)は線 形 移 流 方 程 式 であり、演 算 子 “非 ”分 離 型 の保 存 型 解 法 を用 いる。また式(3)は回 転 流 方 程 式 であり、back-substitution 法 と呼 ばれる演 算 子 分 離 型 の解 法 を用 いる。またこれらの方 程 式 を解 く上 で、物 理 量 の保 存 、解 の無 振 動 性 、正 値 性 の保 証 を満 たす独 自 の 5
次 精 度 保 存 型 無 振 動 スキームを用 いている。
実 空 間 の移 流 （position カーネル）の概 要 をプログラム 1 に、速 度 空 間 の移 流 （velocity_e カー
ネル）の概 要 をプログラム 2 に示 す。両 者 は同 じ演 算 手 法 を用 いているが、数 値 流 束 データを格納 するための一 時 配 列 の容 量 が異 なることが分 かる。分 布 関 数 データの定 義 が、モーメント計 算(速 度 空 間 の積 分 )を高 速 に行 うために f(vx,vy,vz,x,y)となっており、velocity_e カーネルでは数値 流 束 データが l,n,m に依 存 するために 3 次 元 であるのに対 して、position カーネルでは数 値 流
束 データが i,j に依 存 するために 5 次 元 になっている。

115 / 253

プ ロ グ ラ ム 1： position カ ー ネ ル の 概 要
DO j=1,Ny
DO i=1,Nx
DO n=1,Nvz
DO m=1,Nvy
DO l=1,Nvx
dfx(l,m,n,i,j)=... !x 方 向 のフラックスの計 算
dfy(l,m,n,i,j)=... !y 方 向 のフラックスの計 算

f(l,m,n,i,j)=f(l,m,n,i,j)-dfx(l,m,n,i,j)+dfx(l,m,n,i-1,j) &-dfy(l,m,n,i,j)+dfy(l,m,n,i,j-1)
END DOEND DOEND DOEND DOEND DOプ ロ グ ラ ム 2： velocity_e カ ー ネ ル の 概 要
DO j=1,Ny
DO i=1,Nx
DO n=1,Nvz
DO m=1,Nvy
DO l=1,Nvx
dfx(l,m,n)=... !vx 方 向 のフラックスの計 算
dfy(l,m,n)=... !vy 方 向 のフラックスの計 算
dfz(l,m,n)=... !vz 方 向 のフラックスの計 算

f(l,m,n,i,j)=f(l,m,n,i,j)-dfx(l,m,n)+dfx(l-1,m,n) &-dfy(l,m,n)+dfy(l,m-1,n) &-dfz(l,m,n)+dfz(l,m,n-1)
END DOEND DOEND DOEND DOEND DO

116 / 253

2.6.2.3 測 定 環 境
性 能 測 定 には、名 古 屋 大 学 の FX100 を使 用 した。なお、本 測 定 は単 一 ノードで行 い、並 列 性
能 の測 定 は行 わない。コンパイラオプションは以 下 のとおりである。
 -Kfast,visimpact,openmp,preex,simd=2 –x250

2.6.2.4 配 列 の転 置
Position カーネルで用 いる一 時 配 列 の容 量 を減 らすためには、プログラム３で示 すような速 度と位 置 を入 れ替 えた配 列 ftmp(x,y,vx,vy,vz)を用 いる必 要 があるが、これには配 列 の転 置 を行 う
必 要 がある。そこで本 プロジェクトでは、配 列 の転 置 について、プログラム４を用 いて性 能 評 価 を行 った。プログラム４をそのまま 32 スレッドで走 らせると、Nx=166,Ny=86,Nvx=Nvy=Nvz=46 のときに 1 ステップあたり順 方 向 で 2.6 秒 、逆 方 向 で 2.5 秒 程 度 掛 かる。このプログラムを-Kopenmp を除 いてコンパイルすると、順 方 向 逆 方 向 共 にソースリストに以 下 のように表 示 される。
<<<

INTERCHANGED(nest: 2)
do jj=nys-3,nye+3<<<

INTERCHANGED(nest: 4)
do ii=nxs-3,nxe+3<<<

INTERCHANGED(nest: 1)
do nn=nvzs-3,nvze+3<<<

INTERCHANGED(nest: 3)
do mm=nvys-3,nvye+3

し た が っ て 、 n, j, m, i, l の 順 に ル ー プ を 入 れ 替 え た ほ う が 高 速 に な る 。 ま た こ の 場 合 、
COLLAPSE(2)が最 も高 速 であり、このときに 1 ステップあたり順 方 向 で 0.3 秒 、逆 方 向 で 0.23 秒となり、約 10 分 の 1 に短 縮 された。
プ ロ グ ラ ム 3： 転 置 し た 分 布 関 数 を 用 い た position カ ー ネ ル の 概 要
DO n=1,Nvz
DO m=1,Nvy
DO l=1,Nvx
DO j=1,Ny
DO i=1,Nx
dfx(i,j)=... !x 方 向 のフラックスの計 算
dfy(i,j)=... !y 方 向 のフラックスの計 算

ftmp(i,j,l,m,n)=ftmp(i,j,l,m,n)-dfx(i,j)+dfx(i-1,j) &-dfy(i,j)+dfy(i,j-1)
END DOEND DOEND DOEND DOEND DO

117 / 253

プ ロ グ ラ ム 4： 配 列 転 置!順 方 向!逆 方 向!$OMP DO COLLAPSE(3)!$OMP DO COLLAPSE(3)do j=1,Ny

do n=1,Nvz

do i=1,Nx

do m=1,Nvy

do n=1,Nvz

do l=1,Nvx

do m=1,Nvy

do j=1,Ny

do l=1,Nvx

do i=1,Nx

gtmp(i,j,l,m,n)=g(l,m,n,i,j)g(l,m,n,i,j)=gtmp(i,j,l,m,n)

end doend doend doend doend doend doend doend doend doend do!$OMP END DO!$OMP END DO

2.6.2.5 最 適 化 指 示 子 (OCL)
幾 つかのプログラムパターンについて、ループアンロールの最 適 化 指 示 子 (unroll(n))及び、ソフトウェアパイプラインの最 適 化 指 示 子 (noswp)について、その有 効 性 を確 かめた。まず、パ
ターン１－３の全 ての場 合 において、アンロール回 数 を 10 にするのが概 ね高 速 であることが分 かった。次 に、ソフトウェアパイプラインの最 適 化 指 示 子 (noswp)について有 り無 しの場 合 を比 較 した
ところ、ループ内 の配 列 がループの添 え字 を直 接 参 照 している場 合 (パターン１)や、ループ内 の配 列 がループの添 え字 と単 純 な整 数 演 算 を参 照 している場 合 (パターン 2)は、ソフトウェアパイプ
ラインを用 いた(指 示 子 を入 れない)ほうが速 く、ループ内 の配 列 がループの添 え字 と変 数 との演算 になっている場 合 (パターン 3)は、ソフトウェアパイプラインを用 いない(指 示 子 を入 れた)ほうが高 速 であることが分 かった。
プ ロ グ ラ ム 5： 最 適 化 指 示 子 確 認 用 の プ ロ グ ラ ム パ タ ー ン!パ タ ー ン １ ： 配 列 の 単 純 参 照
do n=nvzs,nvze
do m=nvys-1,nvye!OCL UNROLL(10)do l=nvxs,nvxe
vvy(l,m) = vx(l)*bbx+vy(m)*bby+vz(n)*bbz
mm0(l,m) = m-floor(vvy(l,m))
mmv(l,m) = sign(1.0d0,vvy(l,m))
end doend doend do118 / 253

!パ タ ー ン ２ ： 配 列 の 参 照 が 単 純 な 演 算
do n=nvzs-1,nvze+1
do m=nvys-1,nvye+1!OCL UNROLL(10)do l=nvxs-1,nvxe+1
hp2=f(l,mm0(l,m)+2,n,i,j)
hp1=f(l,mm0(l,m)+1,n,i,j)
hp0=f(l,mm0(l,m),n,i,j)hm1=f(l,mm0(l,m)-1,n,i,j)
hm2=f(l,mm0(l,m)-2,n,i,j)dfy(l,m)=pic5(hp2,hp1,hp0,hm1,hm2,vvy(l,m))
end doend doend do!パ タ ー ン ３ ： 配 列 の 参 照 が 変 数 演 算
do n=nvzs-1,nvze+1
do m=nvys-1,nvye+1!OCL NOSWP!OCL UNROLL(10)do l=nvxs-1,nvxe+1
hp2=f(l,mm0(l,m)+mmv(l,m)*2,n,i,j)
hp1=f(l,mm0(l,m)+mmv(l,m),n,i,j)hp0=f(l,mm0(l,m),n,i,j)hm1=f(l,mm0(l,m)-mmv(l,m),n,i,j)hm2=f(l,mm0(l,m)-mmv(l,m)*2,n,i,j)dfy(l,m)=pic5(hp2,hp1,hp0,hm1,hm2,vvy(l,m))
end doend doend do以 上 の OCL の最 適 化 により、プログラム全 体 として 1 ステップあたり 17.7 秒 から 15.7 秒 まで
短 縮 された。

2.6.2.6 まとめ
本 性 能 測 定 で得 られた知 見 は以 下 の通 りである。
 配 列 の転 置 については、OpenMP のオプションを外 してコンパイルしたときに、コンパイラが最適 化 した通 りにループを並 び替 えるのが最 も高 速 であることが分 かった。COLLAPSE などの
デイレクティブはコンパイラの最 適 化 を阻 害 する場 合 がるため注 意 が必 要 である。

119 / 253 ループアンロールの最 適 化 指 示 子 については、ループ長 が割 り切 れる数 若 しくは、ループ長
を SIMD 数 で割 った値 の約 数 にアンロール回 数 を設 定 するのが概 ね高 速 であることが分 かった。
 ソフトウェアパイプラインの最 適 化 指 示 子 については、配 列 の添 え字 が変 数 の演 算 で参 照 されている場 合 は NOSWP を指 定 したほうが高 速 になる場 合 が多 いことが分 かった。

120 / 253

超次元配列の転置

1

Copyright 2015 FUJITSU LIMITED

転置のソースリスト
26
27
28
29
30
31
32

1
2
3
4

p
p
p
p

!$OMP PARALLEL DEFAULT(PRIVATE) &!$OMP SHARED(nxs,nxe,nys,nye,nvxs,nvxe,nvys,nvye,nvzs,nvze,gg,gtmp)!$OMP DO COLLAPSE(3)do jj=nys-3,nye+3(-1 ～ 84 回転)
do ii=nxs-3,nxe+3(-1 ～ 164回転)
do nn=nvzs-3,nvze+3(-1 ～ 44 回転)
do mm=nvys-3,nvye+3(-1 ～ 44 回転)<<< Loop-information Start >>><<< [OPTIMIZATION]<<<
SIMD(VL: 4)<<< Loop-information End >>>do ll=nvxs-3,nvxe+3(-1 ～ 44 回転)
gtmp(ii,jj,ll,mm,nn)=gg(ll,mm,nn,ii,jj)
end doend doストライドアクセス
連続アクセス
end doend do45!$OMP PARALLEL DEFAULT(PRIVATE) &end do46!$OMP SHARED(nxs,nxe,nys,nye,nvxs,nvxe,nvys,nvye,nvzs,nvze,gg,gtmp)!$OMP END DO
47!$OMP DO COLLAPSE(3)!$OMP END PARALLEL48
1 p
do nn=nvzs-3,nvze+3(-1 ～ 44 回転)49
2 p
do mm=nvys-3,nvye+3(-1 ～ 44 回転)50
3 p
do ll=nvxs-3,nvxe+3(-1 ～ 44 回転)51
4 p
do jj=nys-3,nye+3(-1 ～ 84 回転)<<< Loop-information Start >>><<< [OPTIMIZATION]<<<
SIMD(VL: 4)<<< Loop-information End >>>
52
5 p
8v
do ii=nxs-3,nxe+3(-1 ～ 164回転)
53
5 p
8v
gg(ll,mm,nn,ii,jj)=gtmp(ii,jj,ll,mm,nn)
54
5 p
8v
end do55
4 p
end doストライドアクセス
連続アクセス56
3 p
end do57
2 p
end do58
1 p
end do59!$OMP END DO
60!$OMP END PARALLEL

swap(順)

33
34
35
36
37
38
39
40
41

5
5
5
4
3
2
1

p
p
p
p
p
p
p

8v
8v
8v

swap(逆)2

121 / 253

Copyright 2015 FUJITSU LIMITEDループ交換前後のソースリスト
26!$OMP PARALLEL DEFAULT(PRIVATE) &26!$OMP PARALLEL DEFAULT(PRIVATE) &27!$OMP SHARED(nxs,nxe,nys,nye,nvxs,nvxe,nvys,nvye,nvzs,nvze,gg,gtmp)!$OMP SHARED(nxs,nxe,nys,nye,nvxs,nvxe,nvys,nvye,nvzs,nvze,gg,gtmp)
27
28!$OMP DO COLLAPSE(3)28!$OMP DO COLLAPSE(2)29 1 pdo jj=nys-3,nye+3
29 1 pdo nn=nvzs-3,nvze+3
30 2 pdo ii=nxs-3,nxe+3
30 2 pdo jj=nys-3,nye+3
31 3 pdo nn=nvzs-3,nvze+3
31 SWPするため
3 p
do mm=nvys-3,nvye+3
32 4 pdo mm=nvys-3,nvye+3
32 4 pdo ii=nxs-3,nxe+3
33 5 p 8v
do ll=nvxs-3,nvxe+3
33 4!OCL NOUNROLL
34 5 p 8v
gtmp(ii,jj,ll,mm,nn)=gg(ll,mm,nn,ii,jj) 34 5 p v
do ll=nvxs-3,nvxe+3
35 5 p 8v
end do35 5 p v
gtmp(ii,jj,ll,mm,nn)=gg(ll,mm,nn,ii,jj)
36 4 pend do36 5 p v
end do37 3 pend do37 4 pend do38 2 pend do38 3 pend do39 1 pend do39 2 pend do40!$OMP END DO
40 1 pend do41!$OMP END PARALLEL
41!$OMP END DO

 xxx

ループ交換前ループ交換後42!$OMP END PARALLEL
45!$OMP PARALLEL DEFAULT(PRIVATE) &46!$OMP SHARED(nxs,nxe,nys,nye,nvxs,nvxe,nvys,nvye,nvzs,nvze,gg,gtmp)
46!$OMP PARALLEL DEFAULT(PRIVATE) &47!$OMP DO COLLAPSE(3)!$OMP SHARED(nxs,nxe,nys,nye,nvxs,nvxe,nvys,nvye,nvzs,nvze,gg,gtmp)
47
48 1 pdo nn=nvzs-3,nvze+3
48!$OMP DO COLLAPSE(2)49 2 pdo mm=nvys-3,nvye+3
49 1 pdo nn=nvzs-3,nvze+3
50 3 pdo ll=nvxs-3,nvxe+3
50 2 pdo jj=nys-3,nye+3
51 4 pdo jj=nys-3,nye+3
51 3 pdo mm=nvys-3,nvye+3
52 5 p 8v
do ii=nxs-3,nxe+3
52 4 pdo ii=nxs-3,nxe+3
53 5 p 8v
gg(ll,mm,nn,ii,jj)=gtmp(ii,jj,ll,mm,nn) 53 5 p v
do ll=nvxs-3,nvxe+3
54 5 p 8v
end do54 5 p v
gg(ll,mm,nn,ii,jj)=gtmp(ii,jj,ll,mm,nn)
55 4 pend do55 5 p v
end do56 3 pend do56 4 pend do57 2 pend do57 3 pend do58 1 pend do58 2 pend do59!$OMP END DO
59 1 pend do60!$OMP END PARALLEL
60!$OMP END DO
61!$OMP END PARALLEL

3

Copyright 2015 FUJITSU LIMITED

転置(逆)チューニング前後のキャッシュ効率
 L1Dキャッシュとライン数
 64KB/コア 1ライン256バイト(32要素) ・ 256ライン

 チューニング前後のキャッシュミスとキャッシュヒット
チューニング前
gg ( 3 2 1
5 4 ) ←ネスト数( -1, -1, -1, -1, -1 ) キャッシュミス( -1, -1, -1,
0, -1 ) キャッシュミス( -1, -1, -1,
1, -1 ) キャッシュミス::( -1, -1, -1, 164, -1 ) キャッシュミス( -1, -1, -1, -1, 0 ) キャッシュミス( -1, -1, -1,
0, 0 ) キャッシュミス( -1, -1, -1,
1, 0 ) キャッシュミス::( -1, -1, -1, -1, 1 ) キャッシュミス( -1, -1, -1,
0, 1 ) キャッシュミス( -1, -1, -1,
1, 1 ) キャッシュミス::
gtemp (

5

4 3
2
連続アクセス

チューニング後
4
2 5
3-1, -1, -1, -1,-1, -1, 0, -1,-1, -1, 1, -1,:-1, -1, 44, -1,
0, -1, -1, -1,
0, -1, 0, -1,
0, -1, 1, -1,:( 1, -1, 1, -1,
連続( 1, -1, 0, -1,
アクセス( 1, -1, 1, -1,:
gtemp (
(
(
(
連続
アクセス
(
(
(
(

1 ) ←ネスト数

gg (

5

3 1
4
連続アクセス1 ) ←ネスト数-1 )キャッシュミス-1 )キャッシュミス-1 )キャッシュミス:-1 )キャッシュミス-1 ) キャッシュヒット-1 ) キャッシュヒット-1 ) キャッシュヒット:-1 ) キャッシュヒット-1 ) キャッシュヒット-1 ) キャッシュヒット:2 ) ←ネスト数

 チューニング後は、連続アクセスとなることによりキャッシュヒットが増加
4122 / 253

Copyright 2015 FUJITSU LIMITED転置（逆）チューニング結果
 ループ交換によるチューニング
チューニング前 グラフは、32スレッド実行のスレ
ッド0のサイクルアカウンティング
結果

チューニング後 L1Dミス数とL2ミス数が1/10以
下に減少して、性能が向上

L1D ミス率(/
ロード・ストア
数)

ロード・ストア数

L1D ミス数

L2 ミス率(/ロード・ストア数)

チューニング前

58.10%

4.38E+08

2.55E+08

51.28%

2.25E+08

チューニング後

4.44%

4.46E+08

1.98E+07

3.39%

1.51E+07

5

L2 ミス数

Copyright 2015 FUJITSU LIMITED

キャッシュ効率のチューニング
 キャッシュ利用効率を上げられないか？と言う観点でチューニング
を試した→ループ交換でキャッシュ利用効率を上げること確認 転置(順)のループ交換チューニングの性能
イタレーション回数

ループ交換無し（秒）

ループ交換有り（秒）

性能比(無し/有り)

1

3.093

0.750

4.12

2

2.603

0.291

8.95

3

2.606

0.291

8.96

4

2.602

0.291

8.94

5

2.604

0.291

8.95

 転置(逆)のループ交換チューニングの性能
イタレーション回数

ループ交換無し（秒）

ループ交換有り（秒）

性能比(無し/有り)

1

2.528

0.234

10.80

2

2.550

0.234

10.90

3

2.531

0.234

10.82

4

2.531

0.234

10.82

5

2.539

0.234

10.85

6

123 / 253

Copyright 2015 FUJITSU LIMITEDループアンロール

7

Copyright 2015 FUJITSU LIMITED

コードの違い 主なループの違い (nvxs=2、nvxe=41)
 velocity_e (42回転) OCL指定あり
 sb

 fx

!OCL NOSWP!OCL UNROLL(8)do ll=nvxs-1,nvxe+1
hp2=gg(ll,mm,nn+nv+nv,ii,jj)
hp1=gg(ll,mm,nn+nv,ii,jj)
hp0=gg(ll,mm,nn,ii,jj)hm1=gg(ll,mm,nn-nv,ii,jj)hm2=gg(ll,mm,nn-nv-nv,ii,jj)
t_dgz(ll,mm)=pic5(hp2,hp1,hp0,hm1,hm2,fez)
end do!OCL NOSWP!OCL UNROLL(8)do ll=nvxs-1,nvxe+1
hp2=gg(ll,mm,nn+2,ii,jj)
hp1=gg(ll,mm,nn+1,ii,jj)
hp0=gg(ll,mm,nn ,ii,jj)
hm1=gg(ll,mm,nn-1,ii,jj)
hm2=gg(ll,mm,nn-2,ii,jj)
t_dgz(ll,mm)=pic5s(hp2,hp1,hp0,hm1,hm2,fez)
end do ユーザ作成関数pic5sの中で、fezの符号に応じてhp2~hm2を並び替えている。

8

124 / 253

Copyright 2015 FUJITSU LIMITED

velocity_eの性能とソース抜粋
 タイマー性能結果（単位：秒）

velocity_e_sb
velocity_e_fx

do jj=nys-3,nye+3
do ii=nxs-3,nxe+3
処理1
do nn=nvzs-1,nvze+1
do mm=nvys-1,nvye+1
do ll=nvxs-1,nvxe+1!OCL NOSWP
処理2!OCL UNROLL(8)end dodo ll=nvxs-1,nvxe+1
処理3
4‐1 end do
do ll=nvxs-1,nvxe+1!OCL LOOP_NOFUSION
処理4!OCL NOSWP
end do!OCL UNROLL(8)do ll=nvxs-1,nvxe+1
処理5
end doend dodo mm=nvys-1,nvye+1
do ll=nvxs-1,nvxe+1!OCL NOSWP
処理6
4‐2!OCL UNROLL(8)end doend doend dodo nn=nvzs,nvze
do mm=nvys,nvye
4‐3
処理7
end doend doend doend do

区間4-1

区間4-2

13.30914.036

6.969
6.982

 OCL指定している区間4-1,4-2を分析
以降のページで説明 最内ループの回転数は４２回転
 区間4-2はsbとｆｘで同じ

依頼1-1

 最内のネスト5でタイマーを採取するとオーバーヘッドが多くなり正しく取れない。

9

Copyright 2016 FUJITSU LIMITEDUNROLL数を変更した測定結果
 e_sb とe_fxの区間4-1(42回転)の測定結果比較（単位：秒）-Knoswp
区間4-1-Kunroll=N
e_sb
リスタ
1
SIMD 有効16.541(nounroll) SWP 無効
2
12.974〃3
14.082〃
4
13.713〃
5
12.080〃6
14.122〃
7
13.509〃8
13.237〃
9
12.611〃10
12.175〃e_fx
17.36413.45514.19814.31513.76315.07214.60413.91513.87812.951

 UNROLL展開数は、10,5または2が速い
 42回転を4(SIMD)×10回転＋2回転(余り)となり、10回転をUNROLLすることで、2,5,10展開の場合は余りが出ないため速い結果であると考えられる。
10

125 / 253

Copyright 2016 FUJITSU LIMITEDUNROLL数を変更した測定結果
 e_sb とe_fxの区間4-2(42回転)の測定結果比較（単位：秒）-Knoswp
区間4-2-Kunroll=N
e_sb
リスタ
1
SIMD 無効
11.273(nounroll) SWP 無効
2
8.540
〃
3
7.544
〃
4
7.069
〃
5
7.171
〃
6
6.885
〃
7
6.909
〃
8
7.124
〃
9
7.318
〃
10
6.845
〃

e_fx
11.287
8.583
7.575
7.151
7.219
6.848
6.872
7.152
7.331
6.850

 UNROLL展開数は、6,7,10が速い
 SIMDが無効で回転数が42回転であるため、unroll数は割り切れる6,7が高速であったと考えられる。また、unroll数が10も高速であるが、これは命令の並列性などのメリットが余りループ(2回転)のデメリットを上回ったと考えられる。
11

Copyright 2016 FUJITSU LIMITED

ループ最適化処理（複数生成）について
 翻訳時にループ回転数が分からない場合の最適化処理
 翻訳時にループ回転数を考慮した最適化処理を複数生成（以下の）する
この場合、実行時に最適化処理が確定する① SIMD① 230÷96 = 2 余り38 ⇒この処理を2回転
回転数96は翻訳時最適化メッセージ(*)で確認② 38÷(4(SIMD)×8(UNROLL)) = 1 余り6⇒ この処理を1回転③ 6÷4(SIMD) = 1 余り2 ⇒ この処理を1回転④ この処理を2回転* : jwd8205o-I ループの回転数が96回以上の時,ソフトウェア
パイプライニングを適用したループが実行時に選択されます.
12

126 / 253

UNROLL
SWP

高い

命令の並列性 例えばSIMD(4展開),UNROLL(8展開),SWPが行えるループ回転数が230であった場合
以下のように最適化処理が動作する

②

③

低い

SIMD
UNROLLSIMD④
NOSIMD
Copyright 2016 FUJITSU LIMITED2.7 電磁場解析コード ADVENTURE_Magnetic 性能評価
名古屋大学情報基盤センター
荻野 正雄
2.7.1 はじめに

ADVENTURE とは、設 計 用 大 規 模 計 算 力 学 システム開 発 プロジェクト(通 称 ADVENTURE プロジェクト)において開 発 されているオープンソース CAE システムである。大 規 模 メッシュを用 いて自 然 物 や人 工 物 を丸 ごと詳 細 にモデル化 し、多 様 な並 列 分 散 計 算 機 環 境 のもとで固 体 の変 形 や熱 ・流 体 の流 れ等 の力 学 解 析 から可 視 化 、設 計 最 適 化 までを行 える特 徴 がある。無 料 公 開 されていることもあり、
教 育 ・研 究 から産 業 応 用 まで幅 広 く利 用 されているソフトウェアである。ここでは、電 磁 場 解 析 モジュール ADVENTURE_Magnetic の測 定 を行 う。ADVENTURE_Magnetic は、非 線 形 静 磁 場 問 題 、時 間
調 和 渦 電 流 問 題 、さらに非 定 常 渦 電 流 問 題 の有 限 要 素 解 析 機 能 を有 しており、磁 気 ベクトルポテ
ンシャルを未 知 数 とする𝐴𝐴法 または𝐴𝐴 − 𝜙𝜙法 の定 式 化 、ベクトル関 数 を要 素 辺 上 で評 価 する Nédélec

要 素 を用 いている。また、非 構 造 格 子 を用 いた有 限 要 素 解 析 では、大 規 模 で疎 な行 列 を係 数 に持つ連 立 一 次 方 程 式 を解 く必 要 があり、マルチコア・メニーコア上 で高 い並 列 効 率 や演 算 効 率 を出 す
ことが困 難 な分 野 とされている。これに対 し、ADVENTURE_Magnetic は領 域 分 割 法 (Domain Decom
position Method: DDM)を採 用 することで、分 散 メモリ型 並 列 環 境 において高 い並 列 効 率 が得 られ、
将 来 の計 算 機 においても高 性 能 な計 算 が期 待 できるアプリケーションである。
2.7.2 プログラム概要

今 回 は時 間 調 和 渦 電 流 問 題 と非 定 常 渦 電 流 問 題 解 析 を対 象 とする。𝐴𝐴 − 𝜙𝜙法 による定 式 化 は時

間 調 和 渦 電 流 問 題 が、�𝜈𝜈 rot 𝐴𝐴ℎ , rot 𝐴𝐴∗ℎ � − �𝑖𝑖𝑖𝑖𝑖𝑖 𝐴𝐴ℎ , 𝐴𝐴∗ℎ � + �𝜎𝜎 grad 𝜙𝜙ℎ , 𝐴𝐴∗ℎ � = �𝐽𝐽̃ℎ , 𝐴𝐴∗ℎ �

非 定 常 渦 電 流 問 題 が、

(1a)

�𝜎𝜎 grad 𝜙𝜙ℎ , grad 𝜙𝜙ℎ∗ � − �𝑖𝑖𝑖𝑖𝑖𝑖 𝐴𝐴ℎ , grad 𝜙𝜙ℎ∗ � = 0∗
�𝜈𝜈 rot 𝐴𝐴𝑛𝑛+1ℎ , rot 𝐴𝐴ℎ � + �

𝜎𝜎

Δ𝑡𝑡

(1b)

𝑛𝑛+1
∗
∗
̃𝑛𝑛+1 , 𝐴𝐴∗ℎ � + � 𝜎𝜎 𝐴𝐴𝑛𝑛ℎ , 𝐴𝐴∗ℎ �
𝐴𝐴𝑛𝑛+1ℎ , 𝐴𝐴ℎ � + �𝜎𝜎 grad 𝜙𝜙ℎ , 𝐴𝐴ℎ � = �𝐽𝐽ℎ

𝑛𝑛+1
𝑛𝑛
∗
∗
∗
�𝜎𝜎 𝐴𝐴𝑛𝑛+1ℎ , grad 𝜙𝜙ℎ � + Δ𝑡𝑡�𝜎𝜎 grad 𝜙𝜙ℎ , grad 𝜙𝜙ℎ � = �𝜎𝜎 𝐴𝐴ℎ , grad 𝜙𝜙ℎ �

Δ𝑡𝑡

(2a)
(2b)

となる。ここで、𝐴𝐴は磁 気 ベクトルポテンシャル、𝜙𝜙は電 気 スカラーポテンシャル、𝜈𝜈は磁 気 抵 抗 率 、𝐽𝐽は電流 密 度 、𝑖𝑖は虚 数 単 位 、𝜔𝜔は角 周 波 数 、𝜎𝜎は導 電 率 、𝛥𝛥𝛥𝛥は時 間 刻 み幅 、下 付 き添 え字 ℎは有 限 要 素

近 似 、上 付 き添 え字 ∗は任 意 の試 験 関 数 、上 付 き添 え字 𝑛𝑛は時 間 ステップを表 す。式 (1)-(2)より、最終 的 に解 くべき式 は時 間 調 和 渦 電 流 問 題 で複 素 対 称 連 立 一 次 方 程 式 、非 定 常 渦 電 流 問 題 で実対 称 連 立 一 次 方 程 式 となる。さらに、ADVENTURE_Magnetic における DDM では、解 くべき連 立 一
次 方 程 式 を Schur 補 元 方 程 式 へと変 換 する方 法 を採 用 している。まず、解 くべき式 を次 式 で表 す。
𝐊𝐊𝐊𝐊 = 𝐛𝐛(3)

ここで、係 数 行 列 𝐊𝐊は大 規 模 かつ疎 な行 列 となる。次 に、FEM のメッシュを𝑁𝑁個 の部 分 領 域 に分 割 し、領 域 間 境 界 上 自 由 度 への静 的 縮 約 を行 うことで、次 式 で表 される Schur 補 元 方 程 式 が得 られる。
(𝑖𝑖)𝑇𝑇(𝑖𝑖)(𝑖𝑖) (𝑖𝑖)† (𝑖𝑖)(𝑖𝑖)(𝑖𝑖)𝑇𝑇(𝑖𝑖)(𝑖𝑖) (𝑖𝑖)−1 (𝑖𝑖)𝑁𝑁
∑𝑁𝑁
𝐛𝐛𝐼𝐼 �
𝑖𝑖=1 𝐑𝐑 𝐵𝐵 �𝐊𝐊 𝐵𝐵𝐵𝐵 − 𝐊𝐊 𝐵𝐵𝐵𝐵 𝐊𝐊 𝐼𝐼𝐼𝐼 𝐊𝐊 𝐼𝐼𝐼𝐼 � 𝐑𝐑 𝐵𝐵 𝐱𝐱 𝐵𝐵 = ∑𝑖𝑖=1 𝐑𝐑 𝐵𝐵 �𝐛𝐛𝐵𝐵 − 𝐊𝐊 𝐵𝐵𝐵𝐵 𝐊𝐊 𝐼𝐼𝐼𝐼

(4)

ここで、𝐑𝐑は全 体 から部 分 領 域 への自 由 度 制 限 行 列 、下 付 き添 え字 𝐵𝐵は領 域 間 境 界 上 自 由 度 に関する項 、𝐼𝐼は部 分 領 域 内 部 自 由 度 に関 する項 、上 付 き添 え字 (𝑖𝑖)は部 分 領 域 𝑖𝑖に関 する項 、𝑇𝑇は転 置

127 / 253

行 列 、†は一 般 化 逆 行 列 を表 す。この式 は、非 定 常 渦 電 流 問 題 であれば共 役 勾 配 （CG）法 、時 間 調
和 渦 電 流 問 題 は共 役 直 交 共 役 勾 配 （COCG）法 などで解 くことができる。また、必 要 となる係 数 行 列と修 正 方 向 ベクトルの積 演 算 は第 3 回 WG 資 料 7 ページに示 すように、部 分 領 域 ごとの疎 行 列 ベク
トル積 演 算 2 回 と連 立 一 次 方 程 式 解 析 1 回 に置 き換 えられ、部 分 領 域 ごとの連 立 一 次 方 程 式 は不完 全 コレスキー分 解 前 処 理 付 きの CG 法 または COCG 法 で解 いている。疎 行 列 の格 納 形 式 は CSR
を用 いている。
次 に、ADVENTURE_Magnetic のコーディング指 針 について述 べる。本 プログラムは C 言 語 で記 述されている。前 述 のとおり複 数 の解 析 機 能 があるが、それらは有 限 要 素 法 や領 域 分 割 法 の実 装 で共
通 化 できる箇 所 が多 く、また線 形 代 数 関 係 コードも実 数 と複 素 数 の違 い以 外 はほぼ共 通 化 できる。
そこで、第 3 回 WG 資 料 8 ページに示 すように、共 通 コードとマクロ定 義 の組 み合 わせで全 体 のプロ
グラム行 数 を削 減 する工 夫 が行 われている。今 回 はこのようなコードの性 能 評 価 結 果 について紹 介する。
2.7.3 測定環境性 能 測 定 には、名 古 屋 大 学 情 報 基 盤 センターの FX10 と FX100、及 び理 化 学 研 究 所 の京 を使 用した。それぞれの環 境 におけるコンパイラとコンパイラオプションは WG 資 料 に示 す通 りである。
2.7.4 測定結果

まず、ADVENTURE_Magnetic の共 通 化 コードとマクロ定 義 の組 み合 わせによるプログラムに対 する
コンパイラの最 適 化 情 報 について述 べる。第 3 回 WG 資 料 8 ページに示 すように、C プログラムのソースファイルを#include 指 示 で取 り込 んでおり、定 義 したマクロによって例 えば実 数 向 け・複 素 数 向 けとなるように実 装 されている。このようなプログラムを富 士 通 社 製 コンパイラにかけた場 合 、最 適 化 情 報を含 んだソースリストが表 示 されず、最 適 化 作 業 が行 いづらいという問 題 が生 じた。そこで今 回 は、ソースリストを見 るためにインクルードするソースファイルを手 動 で取 り込 んだファイルを別 途 用 意 することで、その問 題 を回 避 した。
次 に、ADVENTURE_Magnetic と同 様 に領 域 分 割 法 を採 用 する構 造 解 析 コード ADVENTURE_So
lid の演 算 性 能 について述 べる。第 3 回 WG 資 料 10 ページに示 すように、FX10 においてピーク性 能
比 4%以 上 が得 られていた。これは、3 次 元 構 造 解 析 では節 点 あたり 3 自 由 度 を持 つため、それを利用 して手 動 ループアンローリングが可 能 であったことが要 因 の 1 つである。しかし、ADVENTURE_Mag
netic では要 素 辺 あたり 1 自 由 度 のみのため、同 様 の最 適 化 を行 えない。これにより、ピーク性 能 比 は
構 造 解 析 に比 べて低 下 することが予 想 される。実 測 した結 果 を第 7 回 WG 資 料 に示 す。6 ページに
as is コード、コンパイラへの最 適 化 指 示 行 追 加 、一 部 のループ入 れ替 え、realloc 関 数 呼 び出 し削
減 を行 ったコードでの FX100 におけるピーク性 能 比 を示 す。非 定 常 渦 電 流 問 題 でピーク性 能 比 0.7～0.9%、時 間 調 和 渦 電 流 問 題 で 1.6%～2.4 程 度 であり、実 数 問 題 における性 能 の低 さが際 立 つ結
果 となった。一 方 、複 素 数 の乗 算 は実 数 に比 べて演 算 強 度 が大 きくなるため、実 行 効 率 が高 くなったと言 える。この複 素 数 問 題 の場 合 について、京 、FX10、FX100 で比 較 した結 果 を 7 ページに示 す。
これより、京 や FX10 に比 べて FX100 での実 行 効 率 が大 きく下 がっていることが分 かる。この点 について考 察 する。FX100 はノードあたり 32 コアで京 の 8 コアや FX10 の 16 コアに比 べて増 加 しているが、FX100 では Core Memory Group（CMG）あたり MPI プロセスを 1 つ起 動 させているため、プロセスあたりのコア数 は FX10 と同 数 であり、8 ページに示 すようにスレッド並 列 効 率 の結 果 も FX10 と同 程 度

128 / 253

であった。そこで SIMD 率 （11 ページ）を調 べたところ、FX10 に比 べて半 分 以 下 になっており、FX100の 4way SIMD を十 分 に活 かせていないことが分 かった。この点 は今 後 改 善 する必 要 がある。
また、三 吉 委 員 より、9 ページの高 コスト関 数 リストで「__lll_lock_wait」や「__pthread_mutex_unlock_u
sercnt」が上 位 にきており、メモリ獲 得 をマスタースレッド以 外 でも頻 繁 に行 っているプログラムであれ
ば、「XOS_MMM_L_ARENA_LOCK_TYPE=0」の環 境 変 数 を指 定 するよう助 言 を頂 いた。その結 果 を
次 表 に示 す。表 より、同 環 境 変 数 の指 定 が有 効 であることが分 かった。
表 1 時 間 調 和 渦 電 流 問 題 における実 行 効 率 [%]の比 較
FX100
as is

1.64

+realloc 呼 び出 し削 減

2.43

環境変数指定2.95

2.7.5 まとめ今 回 の測 定 で得 られた知 見 は以 下 の通 りである。
a) #include 指 示 行 で取 り込 むファイルに対 しては、コンパイラによる最 適 化 情 報 付 きソースリストは出力 されない。
b) 複 素 数 の疎 行 列 ベクトル積 が主 な計 算 となる領 域 分 割 法 において、京 や FX10 に対 し FX100 では実 行 効 率 が半 分 以 下 に低 下 した。SIMD 率 も半 分 以 下 に低 下 しており、SIMD 幅 増 加 に対 して複
素 数 四 則 演 算 の効 率 的 な実 装 が必 要 となる。
c) スレッド並 列 処 理 時 にマスタースレッド以 外 でもメモリ確 保 ・解 放 を繰 り返 す領 域 分 割 法 コードでは、”XOS_MMM_L_ARENA_LOCK_TYPE=0”の指 定 が有 効 である。

129 / 253

アプリ性能評価
電磁場解析「ADVENTURE_Magnetic」
荻野正雄 (名古屋大学)
2014年10月1日
第3回SS研ポストペタアプリ性能WG
第3回WG資料

1

ADVENTUREシステム
External CAD

Utilities
iAgentMaterial
FEMAPtool
onWindows

CAD
TriPatch

Opt Shape
Auto

TetMeshBCtool

IO

Metis
sFlow
Solid Thermal Fluid
Impact Forge Magnetic

今回の対象アプリ

VisualBold: Parallel modules

第3回WG資料130 / 253

2

ADVENTURE_Magneticの概要• 電磁場解析ADVENTURE_Magnetic– 最新バージョン: 1.5 (2014年3月19日公開)– 有限要素法(FEM)による電磁場解析• 非線形静磁場問題, 時間調和渦電流問題, 非定常渦電流問題• A法またはA‐法による定式化• 陰解法• Nédélec四面体1次要素 (ベクトル関数を要素辺上で評価)– 領域分割法(DDM)• Glowinski '84に基づく定式化• 領域分割数N >= プロセス数Np• 計算ノード内は部分領域ループをスレッド並列処理– 言語• C, OpenMP, MPI
第3回WG資料

3

定式化• 静磁場問題rot

実数, 対称∗, rot

AはNédélec四面体1次∗,• 時間調和渦電流問題 複素数, 対称
rot , rot ∗grad , grad

∗

,

∗

grad
, grad• 非定常渦電流問題
rot

∗

, rot
, grad

∗

Δ

Δ

,
grad

∗

∗

,

,

∗

0

φは四面体1次

実数, 対称∗grad, grad∗,∗, grad,∗∗Δ: 磁気ベクトルポテンシャル Wb/m , : 電気スカラーポテンシャル V ,: 磁気抵抗率 m/H , : 電流密度 A/m , : 虚数単位, : 角周波数 rad/s ,0 , Δ : 時間刻み幅 s: 導電率 S/m 不導体領域では第3回WG資料
131 / 253,∗4

領域分割法(DDM)• 線形化された方程式• Non‐overlapping領域分割

辺自由度

領域分割

• Schur補元方程式
ただし,

Krylov部分空間法(CG, COCG)で解く,
領域内部辺(I)または部分領域ごとの項を用いて,,

袖領域辺(B),, 第3回WG資料

5

DDMの実装例• 一般的な実装 (ADVENTUREなど)– Schur補行列を陰に構築
行列ベクトル積演算←• 河合らによる実装 (ADV‐K, '12)
– 部分領域(i)のローカルSchur補行列を陽に構築
行列ベクトル積演算←全体行列の成分が不明のため, 評価できる反復法・前処理法が限定される• 屋・荻野による実装 (LexADV_TryDDM, '13)
– 全体行列を陽に構築
行列ベクトル積演算←

6
第3回WG資料
ほとんどの反復法・前処理法が評価可能で,新しい前処理の開発コストも低い
132 / 253ADVENTUREにおけるコア部分
Schur補行列‐ベクトル積演算• 部分領域ループ内– ① 疎行列ベクトル積– ② ICCG/ICCOCG法で解く

1
1
,

,

←
,

solve
,

,
,

,

←

①
,

,

,
,

←

• ②－１ 疎行列ベクトル積• ②－２ 前進後退代入②,③– ③ 疎行列ベクトル積,←

第3回WG資料

7

ADVENTURE_Magneticの特徴• コーディング指針– 静磁場・渦電流(2種)でFEMやDDM等のコードを共通化– 実数・複素数で線形代数関係のコードを共通化
共通コード＋異なるマクロ#define _real_#include "common.c"#define _complex_#include "common.c"

コンパイラによる最適化情
報付きソースリストが出力されない箇所が多い

コード例(DAXPY)
3017
3018
3019
3020
3021

8
8
8

for( i=0 ; i<nf ; i++ ) {MTYPE dd ;MMULTI( dd, alpha, aq[i] ) ;MPLUS( r[i], r[i], dd ) ;}第3回WG資料133 / 253

SIMD化されない原因が分からないことが多い...

8

数値実験
• テスト問題– 時間調和／非定常渦電流– 無限長ソレノイドコイル→ 長さ0.1m, 中心角20°モデル– 100万(複素)自由度メッシュ• 使用計算機– 名古屋大学Fujitsu PRIMEHPC FX10
12ノード
– コンパイラオプション"‐Kfast,ocl,restp=arg,simd=2,openmp"(名大標準) "‐Kfast ‐g ‐Ntl_trt ‐Xa ‐NRtrap""‐ipo"を指定しようとしたが,名大標準で"‐g"があるので無効になってしまった
第3回WG資料

9

ADVENTURE_Solidのピーク性能比
第9回マルチコアWG時の資料(# Nodes)(12) (24)(6) (12)(24) (48)

第3回WG資料134 / 253(6) (12)
10

"AS IS"コードのピーク性能比
処理

OpenMP並列化ループ

Time‐Harmonic(Complex) [%]Non‐Steady(Real) [%]

all

‐

2.17

0.43

SolveDom

内

3.02

0.67

LoopPart

外

3.61

0.72

SolverCG②式のCG法計算

内

3.55

0.87

mymtMxV
疎行列ベクトル積

内

3.46

1.12

mymtSetBC
境界条件処理

内

8.54

0.20

mymtMakeICC, IC分解

内

0.32

0.27

mymtSetICC, IC前処理

内

3.68

2.01

RealInner, ドット積

内外

0.00

0.45

第3回WG資料11

簡単な改良後のピーク性能比
処理

Time‐Harmonic(Complex) [%]Non‐Steady(Real) [%]

AS IS

TUNED

AS IS

TUNED

all

2.17

2.60

0.43

0.50

SolveDom

3.02

4.09

0.67

0.77

LoopPart

3.61

5.07

0.72

0.83

SolverCG

3.55

3.71

0.87

0.90

mymtMxV

3.46

3.77

1.12

1.19

mymtSetBC

8.54

8.40

0.20

0.21

mymtMakeICC

0.32

0.23

0.27

0.26

mymtSetICC

3.68

3.88

2.01

2.10

RealInner

0.00

0.00

0.45

0.46

第3回WG資料135 / 25312

精密PA結果: SolveDom, 実行時間内訳
時間調和渦電流(複素数)の実行時間内訳

非定常渦電流(実数)の実行時間内訳

第3回WG資料13

精密PA結果: LoopPart, 実行時間内訳
時間調和渦電流(複素数)の実行時間内訳

非定常渦電流(実数)の実行時間内訳

第3回WG資料136 / 25314

精密PA結果: SolverCG, 実行時間内訳
時間調和渦電流(複素数)の実行時間内訳

非定常渦電流(実数)の実行時間内訳

第3回WG資料15

精密PA結果: mymtMxV, 実行時間内訳
時間調和渦電流(複素数)の実行時間内訳

非定常渦電流(実数)の実行時間内訳

第3回WG資料137 / 25316

精密PA結果: mymtSetBC, 実行時間内訳
時間調和渦電流(複素数)の実行時間内訳

非定常渦電流(実数)の実行時間内訳

第3回WG資料17

精密PA結果: mymtMxV (1)メッシュ・キャッシュエンジン ビジー率

SIMD命令率

第3回WG資料138 / 25318

精密PA結果: mymtMxV (2)キャッシュミス率(/ロード・ストア数)

L1Dキャッシュミス内訳(/L1Dキャッシュミス数)

L2キャッシュミス内訳(/L2キャッシュミス数)

第3回WG資料19

精密PA結果: mymtMxV (3)実行時間内訳 [概略] (/実行時間)

命令内訳 (/有効総命令数)

第3回WG資料139 / 25320電磁場解析ADVENTURE_Magneticの
FX100性能評価
荻野正雄 (名古屋大学)
2015年10月8日
第7回SS研ポストペタアプリ性能WG
第7回WG資料1

AdvMagneticにおける実装の特徴• コーディング指針– 静磁場・渦電流(2種)でFEMやDDM等のコードを共通化– 実数・複素数で線形代数関係のコードを共通化
マクロ定義+共通コード
hddm_solver_rs.c#define __ADVMAG_MATRIX_SYSTEM_COMPLEX__#include "mtype.h"#include "hddm_solver.c"

hddm_solver_cs.c

プログラム実体である
hddm_solver.cをincldue文で取り込んでおり, それらはコンパ
イラによる最適化情報付き
ソースリストが出力されない#define __ADVMAG_MATRIX_SYSTEM_REAL__

必要に応じて, 展開してコンパイ
ルしてみて最適化情報を確認#include "mtype.h"#include "hddm_solver.c"
第7回WG資料140 / 2532

四則演算のコーディング方法
for( j=ai[i] ; j<ii ; j++ ) {MTYPE ddd;
MMULTI( ddd, vij[j], vec[aij[j]] );MPLUS( x[i], x[i], ddd );MMULTI( ddd, vij[j], vec[i] );MPLUS( x[aij[j]], x[aij[j]], ddd );}jai i to ii
xi
vij jvec aij j
x aij j
vij j
vec i

• AdvMagneticの実装

v for( j=ai[i] ; j<ii ; j++ ) {v
MTYPE ddd;
6v
MMULTI( ddd, vij[j], vec[aij[j]] );6v
MPLUS( x[i], x[i], ddd );6v
MMULTI( ddd, vij[j], vec[i] );6v
MPLUS( x[aij[j]], x[aij[j]], ddd );
6v }

– 実数
• 関数形式マクロ– 複素数• 構造体(AOS) + 関数
• 構造体(AOS) + 関数形式マクロ• _Complex型#pragma loop norecurrenceを指定する(第6回富士通報告より)ことで, 実数/複素数ともにSIMD化が適用された
第7回WG資料v for( j=ai[i] ; j<ii ; j++ ) {v
MTYPE ddd;
2v
MMULTI( ddd, vij[j], vec[aij[j]] );2v
MPLUS( x[i], x[i], ddd );2v
MMULTI( ddd, vij[j], vec[i] );2v
MPLUS( x[aij[j]], x[aij[j]], ddd );2v }3

並列計算方法と行列サイズ
1

MPI並列化 (MPIプロセスに1つずつ割当)
1

,

,

←
,

solve
,

OpenMP並列化 (スレッドに複数領域を割当)

←
←

,
,

,

,
,
,

,

,

今回は行列サイズは100～200程度となるように
領域分割

,

←

第7回WG資料141 / 2534

数値実験
• テスト問題– 時間調和／非定常渦電流– 無限長ソレノイドコイル→ 長さ0.1m, 中心角20°モデル– 400万(複素)自由度メッシュ– 領域分割数 30,720• 使用計算機

無限長ソレノイドコイル– 名大FX100 4ノード(4,505 Gflop/s)• コンパイラオプション"‐Kfast,ocl,restp=arg,preex,array_private‐Kopenmp"– 東大FX10 4ノード(946 Gflop/s)– 理研AICS京 4ノード(512 Gflop/s)

ケーキモデル

第7回WG資料

5

時間調和問題(複素数)と非定常問題(実数)の比較 @ FX100FLOPS / PEAK [%]Time‐Harmonic(Complex)

Non‐Steady(Real)

asis1.63810.6962

ocl指定

1.69160.7256+一部のループ入れ替え

2.37590.8755+realloc呼び出し回数削減

2.43540.9303複素数問題は実数問題に比べて,
例えば疎行列(CSR)ベクトル積では,・データ読み書き量は2倍・演算量は4倍
第7回WG資料142 / 253jai i to ii
xi
vij jvec aij j
x aij j
vij j
vec i

6

時間調和問題(複素数)におけるK, FX10とFX100の比較
K
Time [s](ratio to
FX100)FX10FLOPS/PEAK [%]

Time [s](ratio to
FX100)

FX100

FLOPS
/PEAK [%]

Time [s]FLOPS/PEAK [%]

asis

626
(3.35)

5.2819424(2.27)

4.2196187

1.6381

ocl指定

604(3.34)

5.4699412(2.28)

4.3455181

1.6916

+一部の
ループ入
れ替え

461
(3.60)

7.1466320(2.5)

5.5657128

2.3759+realloc
呼び出し
回数削
減

441
(3.5)

7.4700298(2.37)

5.98481262.4354

第7回WG資料
KやFX10に比べてFX100での実行効率が大きく下がっている

7

Scalability of multithreads @ FX100# of threads / CMG

Time [s]Speedup ratio

FLOPS/PEAK [%]

1

1,061

1.00

3.6832

2

623

1.70

3.1394

4

324

3.27

3.0199

8

188

5.64

2.5990

16

123

8.63

2.0123

CMGあたりのスレッド並列効率は54%くらいと高くはないが,この傾向はFX10でも同じ

第7回WG資料143 / 2538

時間調和問題(複素数)における高コスト関数@ FX100*************************************************************************************
Application - procedures*************************************************************************************
Cost% Operation (S)------------------------------------------------------------------------------------122204
100.0000
12329.8926
Application------------------------------------------------------------------------------------32830
26.86493312.3438
mymt_CS_AIJ_PC_ICC_set
27776
22.72922802.4683
mymt_CS_AIJ_MxV
16841
13.78111699.4738
hddm_solver_CS_solve_dom
9309
7.6176939.2852
hddm_solver_CS_Parent_loop_part._OMP_2
7041
5.7617710.4250__lll_lock_wait
7040
5.7609710.2708
mymt_CS_AIJ_SetBC_with_bcMat
6136
5.0211619.0325__pthread_mutex_unlock_usercnt
3686
3.0163371.9494
hddm_solver_CS_renewal_bc_sp
3680
3.0114371.2768
mymt_CS_AIJ_Solver_COCG_func
637
0.521364.2622
COM_WriteCpl

このリストはK, FX10, FX100で大差はない
第7回WG資料9

高コスト関数上位3傑の精密プロファイラ情報

4命令
2/3命令
1命令
浮動小数点
ロードL2アク
セス待ち
浮動小数点
演算待ち

浮動小数点
ロードL1Dア
クセス待ち
整数ロード
L1Dアクセス
待ち

SetICC

MxV
第7回WG資料144 / 253

整数ロード
L2アクセス待ち
浮動小数点
ロードメモリアクセス待ちSolveDom

10全体及び高コスト関数のSIMD率
SIMD [%]
FX10

FX100

all

38.7176

16.7654

SetICC
MxV

36.2900
24.0306

15.1750
6.6256

SolveDom

17.9075

7.5875

第7回WG資料145 / 25311

2.8 核融合プラズマ流体解析コード GT5D および GKV の性能測定
日本原子力研究開発機構 井戸村 泰宏、伊奈 拓也、朝比 祐一
名古屋大学 前山 伸也
富士通株式会社 三吉 郁夫、千葉 修一

2.8.1 はじめに
核 融 合 プラズマ流 体 解 析 コード GT5D および GKV は磁 場 閉 じ込 め型 の核 融 合 炉 における炉心 プラズマの閉 じ込 め性 能 を決 定 する乱 流 輸 送 現 象 の評 価 を目 的 として開 発 された。 核融合プ
ラズマの第一原理モデルは 5 次元位相空間（3 次元空間×2 次元速度）におけるプラズマ粒子分布の発展を記述する移流・拡散方程式（ボルツマン方程式）で与えられる（スライド p3、以降、ページ番号のみ表記する）。核融合プラズマ流体解析ではこの方程式を 5 次元格子上で離散化して CFD スキームを適用するため、3 次元流体モデルに比べて〜1002倍程度大きい自由度の流体計算となる。「京」を用いてようやく ITER 規模の炉心プラズマの数値実験を水素、あるいは、重水素のみの単一イオン種のイオン系乱流に対して行うことが可能になったが、電子系乱流を含む数値実験、あるいは、重水素と三重水素を燃料とする核融合反応によってヘリウムが生成される多種イオン系の核燃焼プラズマの数値実験を行うには将来のエクサスケールマシンが必要となる。このような大規模計算を実現する上で最新のメニーコア
プロセッサによって構成される超並列環境の利用技術の高度化が必要不可欠となっている。本性能測定
では、特に、FX100 において強化されたキャッシュ機構や新たに機能拡張されたアシスタントコアの利用技術に焦点を当てて最適化技術の開発およびその有効性検証を行った。

2.8.2 プログラム概 要
GT5D（p4）は炉 心 プラズマ全 体 を計 算 領 域 としてプラズマ乱 流 やプラズマ分 布 の大 域 的 な非線 形 発 展 を追 跡 する。この特 徴 を活 かして、これまで非 局 所 的 な乱 流 輸 送 現 象 の研 究 や乱 流
輸 送 の装 置 サイズスケーリングの研 究 が行 われてきた。計 算 手 法 としては 5 次 元 移 流 ・拡 散 方 程式 に差 分 法 を適 用 し、時 間 積 分 に半 陰 解 法 を用 いている。移 流 項 を陰 的 に計 算 する差 分 ・ 陰
解 法 カーネルは共 役 残 差 法 によって実 装 されており、コードの主 要 コストを占 める。並 列 化 手 法
としては MPI と OpenMP を用 いるハイブリッド並 列 モデルを採 用 している。さらに、OpenMP によって実 装 した通 信 スレッドによる通 信 隠 蔽 処 理 、階 層 的 な多 次 元 領 域 分 割 モデル、および、Tofu
ネットワーク向 けのランクマップ最 適 化 を実 装 することによって、「京 」全 系 に至 る強 スケーリングを
達 成 し、約 1000 億 格 子 を用 いる ITER 規 模 の数 値 実 験 が可 能 になった。本 報 告 では GT5D の差 分 ・陰 解 法 カーネル（GT5D カーネル）を対 象 として FX100 における性 能 測 定 を実 施 する。
GKV（p5）は一 本 の磁 力 線 に沿 った局 所 領 域 を計 算 領 域 として高 解 像 度 のプラズマ乱 流 計
算 を低 コストで行 う。この特 徴 を活 かして、これまで多 くのパラメータスキャンを必 要 とする実 験 データ解 析 やイオンスケールから電 子 スケールにおよぶマルチスケール乱 流 の研 究 が行 われてきた。
計 算 手 法 としては 5 次 元 移 流 ・拡 散 方 程 式 の磁 力 線 に垂 直 な 2 次 元 方 向 に擬 スペクトル法 、それ以 外 の 3 次 元 方 向 に差 分 法 を適 用 し、時 間 積 分 に陽 解 法 を用 いている。非 線 形 項 を擬 スペ
クトル法 で計 算 するカーネルでは 5 次 元 データに対 して並 列 化 2 次 元 FFT を適 用 するため、高コストの転 置 通 信 処 理 が必 要 となる。並 列 化 手 法 としては MPI と OpenMP を用 いるハイブリッド
並 列 モデルを採 用 している。さらに、GT5D と同 様 に OpenMP によって実 装 した通 信 スレッドによる通 信 隠 蔽 処 理 、階 層 的 な多 次 元 領 域 分 割 モデル、および、Tofu ネットワーク向 けのランクマッ

146 / 253

プ最 適 化 を実 装 することによって、「京 」全 系 に至 る強 スケーリングを達 成 し、約 6000 億 格 子 を用いるマルチスケール電 子 乱 流 計 算 が可 能 になった。本 報 告 では GKV のスペクトル法 カーネル（GKV カーネル）を対 象 として FX100 における性 能 測 定 を実 施 する。

2.8.3 通 信 と演 算 のオーバーラップ「京 」全 系 の強 スケーリングを実 現 する上 で通 信 と演 算 をオーバーラップする通 信 マス ク手 法が鍵 となる技 術 となっている。p4 に示 す例 では差 分 演 算 、および、2 次 元 FFT の並 列 処 理 における通 信 オーバーラップの事 例 が示 されている。差 分 演 算 の例 では、通 常 は境 界 データを通 信
してから差 分 演 算 を行 うが、通 信 オーバーラップの場 合 には、差 分 演 算 を境 界 データを参 照 する
周 辺 領 域 とそれ以 外 の中 心 領 域 に分 離 し、後 者 の背 後 で境 界 データの通 信 処 理 を同 時 実 行する。この事 例 では、差 分 演 算 を中 心 領 域 と周 辺 領 域 で分 離 したが、これ以 外 にも異 なる次 元
方 向 に分 離 する、あるいは、異 なる項 毎 に分 離 するといったバリエーションが考 えられる。一 方 、2次 元 FFT の例 では、通 常 は全 データの転 置 処 理 を実 行 してから 1 次 元 FFT を実 行 する処 理 を
繰 り返 すが、通 信 オーバーラップの場 合 には、まず、xy 方 向 の 2 次 元 FFT 処 理 を z 方 向 （GKV
カーネルの場 合 には残 りの 3 次 元 方 向 ）に分 割 する。次 に、異 なる z 方 向 位 置 の FFT と転 置 処
理 を同 時 実 行 する通 信 オーバーラップをパイプライン的 に繰 り返 すことで、高 コストの転 置 通 信 を
隠 蔽 する。
上 記 の通 信 オーバーラップを実 装 する手 法 として「京 」では p8 に示 す通 信 マスク手 法 を開 発 している。この手 法 では OpenMP の MASTER 構 文 によってマスタースレッドを通 信 スレッドとして使用 し、残 りのスレッドに演 算 処 理 を動 的 に割 り当 てる。この実 装 によって、通 信 処 理 の完 了 後 にマスタースレッドも演 算 に復 帰 させ、スレッド間 の負 荷 分 散 を最 適 化 することが可 能 となる。この手
法 は n スレッドを用 いて通 信 処 理 のオーバーヘッドを 1/n に削 減 できるため、今 後 のメニーコア環
境 において非 常 に有 望 な技 術 である。また、通 信 マスク手 法 は標 準 的 な MPI と OpenMP の機 能のみで実 装 可 能 であり、非 同 期 1 対 1 通 信 のみならず、同 期 通 信 や集 団 通 信 も処 理 できるため、極 めて汎 用 性 が高 い。
一 方 、p9 に示 すように、FX100 ではアシスタントコアを用 いる新 たな通 信 オーバーラップが利 用
可 能 である。この機 能 を用 いると、ソースコードの書 き換 えなしに、オーバーラップ区 間 をディレク
ティブで指 定 することによって、対 象 とする演 算 処 理 の背 後 で p10 に示 す MPI-3.0 の非 同 期 通
信 処 理 をアシスタントコアで同 時 実 行 することができる。以 下 では GT5D カーネルの境 界 データ
通 信 と GKV カーネルの転 置 通 信 を対 象 にこの機 能 の有 効 性 を検 証 する。

2.8.3.1 GT5D カーネルにおける境 界 データ通 信 のオーバーラップ
まず、GT5D カーネルを用 いて通 信 オーバーラップの効 果 を調 べた。このカーネルは境 界 デー
タ通 信 を含 む xyzv 方 向 の 4 次 元 差 分 演 算 を行 うが、領 域 分 割 は xy 方 向 の 2 次 元 方 向 のみとなっている。このため、差 分 演 算 のループを zv 差 分 演 算 と xy 差 分 演 算 に分 離 し、zv 差 分 演 算の背 後 で境 界 データ通 信 を実 行 し、その後 で xy 差 分 演 算 を実 行 する。通 信 処 理 は p12 に示 す
5 パターンの実 装 を用 意 した。
•

original 版 ：MPI_Isend/Rrecv/Waitall を連 続 して実 行 し、通 信 の同 期 をとってから差
分 演 算 を実 行 。

•

overlap 版 ：マスタースレッドのみが MPI_Isend/Rrecv/Waitall を実 行 し、他 は演 算 処
理 を実 行 。

147 / 253

•

unroll 版 ：32 スレッドの FX100 で十 分 なループ長 を確 保 するために外 側 2 重 ループ
を 1 重化。

•

unroll+overlap 版 ：unroll 版 でオーバーラップを実 装 し、演 算 負 荷 バランスを改 善 。

•

通 信 スレッド解 除 版 ：unroll+overlap 版 において MASTER 構 文 を削 除 し、MPI_Isend/Recv、および、MPI_Waitall をそれぞれ演 算 処 理 の前 後 に発 行 。さらに、スレッドスケ
ジューリングを DYNAMIC から STATIC に変 更 。

FX100 における性 能 測 定 結 果 を p13 に示 す。ここで、処 理 時 間 はマスタースレッドで計 測 した
境 界 データコピー（copy 区 間 ）、xy 差 分 演 算 （kernel 区 間 ）、通 信 処 理 （waitall 区 間 ）、および、
zv 差 分 演 算 （kernel_p 区 間 ）の内 訳 を示 す。マスタースレッドを通 信 スレッドとして使 用 する overlap 版 、および、unroll+overlap 版 では zv 差 分 演 算 と通 信 処 理 の同 時 実 行 により kernel_p 区 間がマスタースレッド上 で縮 小 する。一 方 、アシスタントコアを用 いる通 信 スレッド解 除 版 （通 信 促 進あり）では通 信 処 理 の大 部 分 がマスタースレッドからアシスタントコアに移 行 するため、waitall 区
間 が縮 小 する。overlap 版 では 16 スレッド（1CMG）に対 し、OpenMP を適 用 している最 外 の x 方
向 のループ長 が 32 となるのに対 し、unroll+overlap 版 では xy 方 向 のループ長 が 1024 となり、ス
レッド間 の動 的 負 荷 分 散 のバランスが改 善 する。通 信 スレッド解 除 版 では、アシスタントコアを用いない場 合 には unroll 版 とほぼ同 じコスト分 布 となるが、アシスタントコアを用 いる通 信 促 進 を適
用 することにより、従 来 の通 信 マスク手 法 を上 回 る性 能 を達 成 した。p14 に示 す kernel_p 区 間 の
詳 細 プロファイラでは、unroll+overlap 版 ではマスタースレッドの演 算 数 はほぼゼロとなり、通 信 処
理 に専 有 されているが、通 信 スレッド解 除 版 （通 信 促 進 あり）では、マスタースレッドも含 めてほぼ
均 等 な演 算 量 となっていることがわかる。しかしながら、MPI 起 動 処 理 とアシスタントコアへの移 行
処 理 のオーバーヘッドが残 っており、静 的 スレッドスケジューリングを行 った場 合 には約 5%程 度の遅 延 がマスタースレッドで発 生 している。このため、アシスタントコアを利 用 する場 合 でも動 的 ス
ケジューリングを用 いてスレッド間 の負 荷 分 散 を最 適 化 する必 要 があることに注 意 が必 要 である。

2.8.3.2 GKV カーネルにおける転 置 通 信 のオーバーラップ
次 に、GKV カーネルを用 いて通 信 オーバーラップの効 果 を調 べた。このカーネルは k x k y zvw
空 間 の 5 次 元 データに対 して k x k y 波 数 空 間 の 2 次 元 逆 フーリエ変 換 を実 行 し、擬 スペクトル法
によって xy 実 空 間 で非 線 形 項 を計 算 した後 で非 線 形 項 を再 び k x k y 波 数 空 間 に 2 次 元 順 フー
リエ変 換 する。この処 理 を w 方 向 にパイプライン化 し、w 方 向 のインデックスの異 なる転 置 通 信 とFFT 処 理 、および、非 線 形 項 計 算 をオーバーラップする。通 信 処 理 は p16 に示 す 5 パターンの
実 装 を用 意 した。
•

オーバーラップなし MPI_Alltoall 版 ：MPI_Alltoall を用 いる転 置 通 信 と FFT 処 理 を
逐 次 的 に実 行 するオリジナル版 。

•

オーバーラップあり MPI_Alltoall 版 ：FFT 処 理 の背 後 でマスタースレッドが MPI_Allt
oall を用 いる転 置 通 信 を同 時 実 行 。

•

オーバーラップなし MPI_Ialltoall 版 ：MPI-3.0 の非 同 期 集 団 通 信 MPI_Ialltoall を用
いる転 置 通 信 と FFT 処 理 を逐 次 的 に実 行 。

•

オーバーラップあり MPI_Ialltoall 版 ：FFT 処 理 の背 後 でアシスタントコアが MPI_Iallt
oall を用 いる転 置 通 信 を同 時 実 行 。

•

オーバーラップあり MPI_Ialltoall、静 的 スレッドスケージュール版 ：オーバーラップあり
MPI_Ialltoall 版 においてスレッドスケジューリングを DYNAMIC から STATIC に変 更 。

148 / 253

FX100 における性 能 測 定 結 果 を p17 に示 す。ここで、処 理 時 間 はマスタースレッドで計 測 した
逆 フーリエ変 換 用 の転 置 通 信 （Comm.(bwd)）、FFT（Comp.(bwd)）、順 フーリエ変 換 用 の転 置
通 信 （Comm.(fwd)）、FFT（Comp.(fwd)）、および、非 線 形 項 処 理 等 （Others）の内 訳 を示 す。マスタースレッドを通 信 スレッドとして使 用 するオーバーラップあり MPI_Alltoall 版 ではマスタースレ
ッドが転 置 通 信 を実 行 するため FFT の処 理 コストが縮 小 する。一 方 、アシスタントコアを用 いるオ
ーバーラップあり MPI_Ialltoall 版 では通 信 コストの一 部 がマスタースレッドからアシスタントコアに移 行 しマスタースレッドから見 えなくなる。測 定 結 果 では通 信 マスク手 法 が最 も良 い性 能 を示 しているが、非 同 期 集 団 通 信 とアシスタントコアの利 用 でも同 程 度 の性 能 向 上 が確 認 できた。アシス
タントコア利 用 によるスレッド間 の負 荷 分 散 の均 等 化 を期 待 して、オーバーヘッドの少 ない静 的 ス
レッドスケジューリングを適 用 した結 果 、性 能 が低 下 した。また、オーバーラップあり版 では、スレッド同 期 の回 数 が減 少 するため、スレッド間 の負 荷 バランスが改 善 し、Others 区 間 のコストが減 少 している。
より詳 細 なコスト分 析 を p18 に示 す。通 信 コストを比 較 した結 果 、オーバーラップあり/なし、MPI_Alltoall/MPI_Ialltoall、全 ての組 み合 わせでほぼ同 等 の通 信 コストとなることがわかった。インターコネクトのバンド幅 とメモリバンド幅 は一 桁 以 上 異 なることから、通 信 オーバーラップ適 用 時 の演
算 処 理 による通 信 性 能 への影 響 は限 定 的 である。また、MPI_Ialltoall では Tofu 向 け高 速 アル
ゴリズムが利 用 できないが、今 回 テストを行 った小 規 模 ノード数 では性 能 劣 化 は少 ないことがわかった。MPI-3.0 の MPI_Ialltoall は非 同 期 集 団 通 信 であるが、MPI_Isend/Irecv と同 様 にアシスタ
ントコアを用 いないと非 同 期 に動 作 しないことに注 意 が必 要 である 。アシス タン トコアを用 いる場
合 には通 信 コストが約 3/1 に減 少 するが、MPI_Ialltoall の起 動 とアシスタントコアへの処 理 移 行のオーバーヘッドがかなり残 っている。
スレッド間 の負 荷 バランスを p11 に示 す。オーバーラップなしの場 合 にはマスタースレッドの通信 処 理 の間 、残 りのスレッドにかなり大 きいバリア同 期 待 ちのコストが見 られる。オーバーラップありの場 合 にはスレッド間 の負 荷 分 散 が改 善 し、バリア同 期 待 ちのコストが大 幅 に減 少 する。しかしながら、アシスタントコアを利 用 して静 的 スレッドスケジューリングを適 用 すると、MPI_Ialltoall 起
動 とアシスタントコアへの移 行 処 理 のオーバーヘッドによってスレッド間 の負 荷 バランスが崩 れて
再 びバリア同 期 待 ちのコストが顕 在 化 する。このため、動 的 スレッドスケジューリングによって負 荷
分 散 を均 等 化 する実 装 が最 も良 い性 能 となった。アシスタントコアの利 用 によって比 較 的 簡 易 に
通 信 オーバーラップを実 現 できることを集 団 通 信 についても示 したが、大 規 模 問 題 で Tofu 専 用
アルゴリズムの利 用 が必 須 となる場 合 には従 来 の通 信 マスク手 法 の利 用 が推 奨 される。

2.8.4 GT5D カーネルにおける演 算 処 理 の性 能 測 定
FX100 で強 化 されたキャッシュ機 構 等 、演 算 機 能 を評 価 するために GT5D カーネルの逐 次 処
理 性 能 を「京 」と FX100 で比 較 した。p21 に示 す GT5D カーネルは xyzv 方 向 の 4 次 元 移 流 項
を 4 次 精 度 中 心 差 分 によって評 価 する 17 ステンシルの計 算 となっている（ここでは、逐 次 処 理 性
能 を比 較 するため、通 信 オーバーラップの際 に適 用 した zv 差 分 演 算 と xy 差 分 演 算 の分 割 は適用 していない）。ソースコードにおいて浮 動 小 数 点 演 算 数 は 35Flop となるのに対 し、メモリアクセ
ス数 は 32B となる。ここで、l-2~l+2、k-2~k+2、j-2~j+2 の範 囲 はコアあたりのキャッシュサイズ以 下となるため、オンキャッシュとして取 り扱 う。i-2~i+2 についてはメモリアクセスとなるが、動 的 スケジューリングを適 用 する場 合 には隣 接 スレッドがロードしたデータを共 有 キャッシュ上 で再 利 用 できるため、やはりオンキャッシュとして取 り扱 う。この結 果 、メモリアクセスは f(l,k,j,i)、fc(l,k,j,i)のロー

149 / 253

ド、および、df(l,k,j,i)のロード・ストアで合 計 4 となり、演 算 密 度 は Flop/Byte~1.1 となる。この演 算
密 度 からルーフラインモデルによって見 積 もった演 算 性 能 の対 ピーク性 能 比 は「京 」、および、FX
100 でそれぞれ 28.4%、および、25.1%となるが、実 測 した演 算 性 能 は約 半 分 となり、理 論 的 な予
測 を大 幅 に下 回 っている。プロファイラの数 値 を比 較 すると、「京 」では L1D ミス数 が大 きく L1D ミ
ス dm 率 （プリフェッチが効 かない実 質 的 な L1D ミスの比 率 ）も高 い。一 方 、FX100 では L2 ミス d
m 率 （プリフェッチが効 かない実 質 的 な L2 ミスの比 率 ）が高 く、FMA 命 令 率 （ここでは浮 動 小 数
点 命 令 数 に対 して定 義 ）が「京 」よりかなり低 いことがわかった。ここで、非 FMA 命 令 では FMA 命
令 の半 分 の演 算 しか処 理 できないため、FMA 命 令 率 が低 いと処 理 性 能 が劣 化 する。
この状 況 をより詳 しく調 べるために、p22 ではさらにカーネルを簡 約 化 し、定 数 係 数 の 17 ステン
シル計 算 を行 った。この結 果 、「京 」ではルーフラインモデルによる対 ピーク性 能 比 の 8 割 以 上 の演 算 性 能 を達 成 した。プロファイラの数 値 を見 ると、「京 」では L1D ミス数 が p24 の理 論 見 積 とほ
ぼ一 致 し、L1D ミス dm 率 、L2 ミス dm 率 も低 く、ほぼ理 想 的 なメモリアクセスが実 現 していることがわかった。ここで、L1D ミス数 の理 論 評 価 は同 じキャッシュライン上 の l-2~l+2、および、プリフェッチされる 3 キャッシュライン上 の k-1~k+1 までを含 む 7 要 素 をオン L1 キャッシュとして扱 い、残 りの 10 要 素 にループ回 転 数 をかけてキャッシュラインサイズで割 った値 によって定 義 している。また、
ソースコードは典 型 的 な積 和 処 理 のパターンになっており、FMA 命 令 率 も 9 割 以 上 という理 想 的な性 能 となっていた。一 方 、FX100 ではキャッシュラインサイズが 128B から 256B に拡 張 されたことに伴 い L1D ミス数 が半 減 し、L1 キャッシュについてはほぼ理 想 的 な性 能 が得 られているが、L2
ミス dm 率 が高 くプリフェッチの効 率 が低 い、また、FMA 命 令 率 が低 いという問 題 が明 らかになった。
次 に、p23 では係 数 を定 数 から配 列 に変 更 し、17 ストリーム版 に近 い形 に修 正 した。この結 果 、「京 」では L1D ミス数 、および、L1D ミス dm 率 が増 大 し、演 算 性 能 がルーフラインモデルによる理論 的 な予 測 から大 幅 に劣 化 することが確 認 された。L1 キャッシュが 2way の「京 」ではループ内 の配 列 数 の増 大 に伴 って、L1 キャッシュ競 合 が頻 発 する。この問 題 の回 避 策 としては、通 信 オー
バーラップで適 用 したようなループ分 割 によってループ内 の配 列 数 を調 整 することが有 効 である。
一 方 、FX100 では L1 キャッシュが 4way に増 え、キャッシュラインサイズも 256B に拡 張 されているため、「京 」で顕 在 化 したような L1 キャッシュ競 合 は見 られず L1D ミス数 は変 化 しなかった。ただし、L1D ミス dm 率 が増 大 しており、プリフェッチの効 率 が劣 化 していることがわかった。
以 上 の性 能 測 定 結 果 から、FX100 では「京 」の弱 点 であった L1 キャッシュの問 題 が解 消 しているが、FMA 命 令 率 とプリフェッチ効 率 の低 下 という新 たな問 題 が発 生 していることがわかった。
この 2 つの問 題 の原 因 調 査 を行 ったが、本 報 告 書 の執 筆 時 点 でプリフェッチ効 率 低 下 の問 題 は
未 解 決 であったため、以 下 では FMA 命 令 率 の問 題 について調 査 結 果 をまとめる。

2.8.4.1 FX100 における FMA 命 令 率 低 下
FMA 命 令 率 低 下 の原 因 調 査 にあたり、コンパイラの動 作 を解 析 した結 果 、ループボディの演
算 特 性 に応 じてコンパイラが以 下 の 2 つの最 適 化 アルゴリズムから最 適 と判 断 されるものを選 択
していることがわかった。p26 の FMA 促 進 アルゴリズムでは積 和 型 の多 項 式 演 算 を FMA 命 令 の繰 り返 しによって深 い木 構 造 で表 現 するのに対 し、p27 の並 列 化 促 進 アルゴリズムでは同 じ演 算を非 FMA 命 令 が多 い浅 い木 構 造 で表 現 する。前 者 は FMA 命 令 率 が高 い最 適 化 であるが、命令 の並 列 度 が低 くソフトウェアパイプライニングが有 効 化 できるル ープに対 して高 い性 能 を発 揮する。一 方 、後 者 は FMA 命 令 率 が低 いが、命 令 の並 列 度 が高 く、ソフトウェアパイプライニング

150 / 253

がそれほど効 かない場 合 でも、命 令 スケジューリングを最 適 化 できる。通 常 はコンパイラが自 動 的にどちらの最 適 化 を採 用 するか選 択 するが、今 回 は強 制 的 に 2 つの最 適 化 アルゴリズムを適 用し、p28 に示 すループボディのサイズが異 なる 5 つのプログラムの処 理 性 能 を比 較 した。
p.29 に 9 ステンシルのコード C の処 理 性 能 を示 す。このプログラムに対 してコンパイラは並 列 化
促 進 アルゴリズムを選 択 するため、オリジナルの場 合 には FMA 命 令 率 （ここではロード・ストア、整
数 演 算 等 を含 む全 命 令 数 に対 して定 義 ）が低 くなる。これに FMA 促 進 アルゴリズムを適 用 すると
FMA 命 令 率 は FX10 とほぼ同 じ値 に向 上 するが、処 理 速 度 は低 下 する。ここで、FMA 促 進 アルゴリズムを適 用 した場 合 には SIMD 幅 が 128bit の FX10 に比 べて SIMD 幅 が 256bit の FX100
では総 命 令 数 がほぼ半 分 になる。p30 に 5 つのプログラムに対 する最 適 化 アルゴリズムの比 較 を示 すが、ループボディが小 さい場 合 には並 列 化 促 進 アルゴリズムが有 効 であるが、ループボディ
が大 きくなるにつれて FMA 促 進 アルゴリズムの性 能 が逆 転 する傾 向 にあることがわかった。p22の簡 約 化 カーネルに相 当 するコード D の場 合 には、コンパイラは並 列 化 促 進 アルゴリズムを選 択していたが、この調 査 結 果 から FMA 促 進 アルゴリズムの方 が高 い処 理 性 能 を示 すことがわかった。

2.8.5 まとめ
核融合プラズマ流体解析コード GT5D、および、GKV の主要計算カーネルを対象として FX100 の新機
能の有効性を検証した。アシスタントコアを利用した通信オーバーラップでは 1 対 1 通信、および、集団通信の両方に対して従来の通信マスク手法と同程度の処理性能が得られたが、MPI を起動してアシス
タントコアに処理を移行するまでのオーバーヘッドが無視できないため、通信マスク手法と同様の動的スケジューリングによるスレッド間の負荷分散の最適化が必要である。演算性能に関しては、L1 キャッシュの機能強化によって「京」の弱点であった L1 キャッシュ競合が改善しているが、「京」に比べて F
MA 命令率やプリフェッチ効率が低下するという新たな問題点が明らかになった。これらの問題は今後のコンパイラ改善によって解消されるものと期待する。

151 / 253ĆóûąöåăĐU Æn,ăďôć|ïĖü ÏáÝ ÜU}@`g)<"¶tr
Vh{?É;Y Éew/+G9=
!H 
B7¯mM
-´:É'ïĖüÜq¡

152 / 253Â6ŎśĽœÎę¶0¡Ï·ŗńŝ     





ŎśĽœ

Yę¯Ţosw°`∂f= G[f ] + C[f ]∂t∂f∂f− U2 [φ]G[f ] = −U1 [φ] ·ä,ĤEĘĥĨ¯
∂R
∂v

2

∂
∂
· (D1 f ) +: (D2 f )C[f ] = −ĵţşšÄ´+∂v∂v∂v
EĪĢĨŒĭĿšw°`−∇⊥ · (P1 ∇⊥ φ) + P2 (φ − φ) = ρ[f ]KB¨ŗńŝŤ #ÿ#Xn,ăďôć
Vm¨ŗńŝŤ ÿ!Xť$  ť"|ïĖüÂÄÀÁÜq¡

Gyrokinetic Toroidal 5D Eulerian code>ûĖďóµÛÏÎØ5uòČæē±%©ċúđÛáãn,TăďôćÜ) |¤ñĈčĒĖñĎĔä ÎÉ |­®Uä¦¤Xz
MPI+OpenMPÿæĂĐøü ċúđ
5u·Ü|ĕZ\ÈIza·È(¹đĔîĕëøöz
ėéĖýđÈPvIz+¯ºĘ¤¢sėITER¢sĘ
610x128x610x96x20 ~ 1000o<~105óùøă
È4þĖüa·/ñĎøû*^5u·ė°L2uĘÜ[%<J

v⊥
v//
z

Idomura et al., Comput.Phys.Commun.2008
Idomura et al., Nucl. Fusion 2009
Idomura et al., Int. J. HPC Appl. 2014
Idomura-Nakata, Phys. Plasmas 2014
Idomura, Phys. Plasmas 2014

y

v⊥
v//

x

GT5DïĖüÜóûēĔìóíĖĐĔì

589,824cores
K (2013)
65,536cores
Helios (2012)
16,384cores
BX900 (2011)

(NR,Nζ,NZ,Nv//,Nμ)=(768,64,768,128,32)

4

153 / 253n,ăďôć








|ïĖüÂÃÅÜq¡

GyroKinetic Vlasov code"Ûy×ÖFW¾5ÛÏÎØ5uòČæē±%©ċúđÛáãn,TăďôćÜ) |¤äÎÉ |­®Uä¦Õã¤Xz
MPI+OpenMPÿæĂĐøü ċúđ
5u·Ü|ĕZ\Èóąëûđz(x,y)ÉIz(z,v,w)
a·ÈđĔîĕëøöz
ėéĖýđÈ2uFFT+¯ºĘ¤¢s1024x1024x96x96x32x2 ~ 6000o<~105óùøă
È4þĖüa·/ñĎøû*^GKVÛáãćđ÷óíĖđ¼<


|¤

 SóíĖđ
¼<¬²(Q0.1mm
æèĔ¬²(Q5mm→503Ü£LGKVïĖüÜóûēĔìóíĖĐĔì

Watanabe-Sugama, Nucl. Fusion 2006
Watanabe et al., Phys. Rev. Lett. 2008
Maeyama et al., Parallel Computing 2015
Maeyama et al., Phys. Rev. Lett. 20155¯Ú~ÜèĖĀĖďøă

154 / 253áĕ·ę7y¡ĘĥĨıţŊţŏŃņ&áńţŀĕµė·¡Ě0¡¨Ę7y¡Ć4¿õB (ČĐX ·ęF¥ńţŀĪü1ĎĨ·
ĕý1ČėĂ·Ę ð·¡ýę¾dĔF¥ńţŀęTáĪQÃeęn

vČĂn

ťF¥ńţŀáťF¥ńţŀáĕhõBę7y¡!- ę ńţŀÙ¼ÿĪēw
8Ę ( w8Ę¦ĨįšńŃĵļę
ńţŀÙ¼ĕĪ7y¡eęn

vČĂn

ťńţŀÙ¼¡ťw8ĘµėńţŀÙ¼ĕĪ7y¡




ťX

ť;ÜõBęX

Ï·Ï·ť

ťw8Ę7ę¡áĕ·ę7y¡ĪQĎĨáœļĵn  ĔáļŞŃņĪQÇČÿNìęĂáĕ·Ī7y¡ 2T2áŤ7|áÿñ7|áť X
Ï·ęÆõBáŤ6ÿ ť ïAá
 J!-Ť ť ńţŀÙ¼¡Ť6ť',&! 

8,

',&! 

2345+ 2345+#"!
*

áĸļŅĪ2,Ę&)
áĸţńĮšĶęįŖţĻ)0   )0  
  %#)0   
)0  -  .

%#)0    *
7

155 / 253䜰䝅䝇䝍䞁䝖䝁䜰䛻䜘䜛㏻ಙ䜸䞊䝞䝷䝑䝥ಁ㐍 䜰䝅䝇䝍䞁䝖䝁䜰䛻㏻ಙฎ⌮䜢௵䛫䜛䜛౑⏝᫬䛾ືస䜲䝯䞊䝆

 MPI䝷䜲䝤䝷䝸䛻ືస䝰䞊䝗䜢㏣ຍ
a. progress thread䛺䛧 (䝕䝣䜷䝹䝖)b. progress thread䛒䜚
i.
ii.
iii.

⮬ື༊㛫䝰䞊䝗
ᣦᐃ༊㛫MPI࿧䜃ฟ䛧䛺䛧䝰䞊䝗ᣦᐃ༊㛫MPI࿧䜃ฟ䛧䛒䜚䝰䞊䝗 ືసᴫせ:䜰䝅䝇䝍䞁䝖䝁䜰䛜䝜䞁䝤䝻䝑䜻䞁䜾㏻ಙฎ⌮䛾኱༙䜢ᐇ⾜ᑐ㇟༊㛫䜢᫂♧䛩䜛ሙྜ ฼⏝⪅䛾ᑐฎ
1. MCA䝟䝷䝯䞊䝍䛷progress thread᭷↓䜢㑅ᢥ
2. ᚲせ䛻ᛂ䛨䛶䚸䜸䞊䝞䝷䝑䝥㏻ಙ䛾ᑐ㇟༊㛫䜢ᣦᐃ••

FJMPI_Progress_start: 㠀ྠᮇ㏻ಙ䛾ಁ㐍ฎ⌮䜢㛤ጞ
FJMPI_Progress_stop: 㠀ྠᮇ㏻ಙ䛾ಁ㐍ฎ⌮䜢೵Ṇ叏吁  ಁ呎 㐍 吧ᑐ呀吚 
㇟ 吮
༊㏻
   
㛫ಙ᤼௚ไᚚ䜸䞊䝞
䝦䝑䝗䜢๐ῶ 䝯䝸䝑䝖: 䝁䞊䝗᭩䛝᥮䛘䛺䛧䛻䜸䞊䝞䝷䝑䝥㏻ಙ䛜ྍ⬟䚸⡆᫆䛺༊㛫ᣦᐃ䛷᤼௚ไᚚ䜸䞊䝞䝦䝑䝗䜒ᢚไ䛷䛝䜛3

Copyright 2014 FUJITSU LIMITED

MPI-3.0䛾䝜䞁䝤䝻䝑䜻䞁䜾㞟ᅋ㏻ಙAPI (ᢤ⢋)
 1ᑐከ㏻ಙ
 MPI_IBCAST(buffer, count, datatype, root, comm, request)
 MPI_ISCATTER(sendbuf, sendcount, sendtype, recvbuf, recvcount,recvtype, root, comm, request) ከᑐ1㏻ಙ
 MPI_IGATHER(sendbuf, sendcount, sendtype, recvbuf, recvcount,recvtype, root, comm, request) ከᑐከ㏻ಙ
 MPI_IALLGATHER(sendbuf, sendcount, sendtype, recvbuf, recvcount,recvtype, comm, request)
 MPI_IALLTOALL(sendbuf, sendcount, sendtype, recvbuf, recvcount,recvtype, comm, request) 䝸䝎䜽䝅䝵䞁
 MPI_IREDUCE(sendbuf, recvbuf, count, datatype, op, root, comm,request) MPI_IALLREDUCE(sendbuf, recvbuf, count, datatype, op, comm,request) 䝞䝸䜰ྠᮇ
 MPI_IBARRIER(comm, request)
6

156 / 253

Copyright 2015 FUJITSU LIMITED éĖýđÛÏÓã
6úĖö¯ÜèĖĀĖďøă

㏻ಙ䜸䞊䝞䝷䝑䝥ຠᯝ䛾ホ౯(1/3)
unroll+overlap∧䛾䝁䞊䝗䜲䝯䞊䝆 ホ౯᮲௳
ᐃ⎔ቃ
• FX100 32䝜䞊䝗 (1.975GHz䚸32.4Tflops)• FX10 64䝜䞊䝗 (1.848GHz䚸15.1Tflops)ᐃ᮲௳• ၥ㢟䝃䜲䝈:nnx㽢nny㽢nnz㽢nnv䠙256㽢256㽢64㽢128• ୪ิᩘ:
npx㽢npy䠙8㽢8 (16䝇䝺䝑䝗㽢64䝥䝻䝉䝇) ౑⏝䝞䜲䝘䝸

!$OMP PARALLEL!$OMP MASTERMPI_Isend㏻ಙ䝇䝺䝑䝗ゎ㝖∧䛷䛿ศ㞳䛧䚸₇⟬ฎ⌮ᚋ䛻⛣ືMPI_Irecv
MPI_Waitall!$OMP END MASTER!$OMP DO SCHEDULE(DYNAMIC)
do ij=…
₇⟬ฎ⌮
enddo!$OMP END PARALLEL• original∧: MPI_Isend/Irecv/Waitall䜢㐃⥆䛧䛶ᐇ⾜• overlap∧: 䝬䝇䝍䝇䝺䝑䝗䛜MPI_Isend/Irecv/Wait䜢ᐇ⾜䛧䚸௚䛿₇⟬ฎ⌮䜢ᢸᙜ• unroll∧: ㏻ಙ┤ᚋ䛾₇⟬ฎ⌮(kernel_p༊㛫)䛷እഃ2㔜䝹䞊䝥䜢୍㔜໬• unroll+overlap∧: overlap∧䛸unroll∧䜢⼥ྜ䛥䛫䚸₇⟬㈇Ⲵ୙ᆒ⾮䜢ᨵၿ• ㏻ಙ䝇䝺䝑䝗ゎ㝖∧: unroll+overlap∧䜢䜒䛸䛻䚸MPI_Waitall䜢₇⟬ฎ⌮ᚋ䛻⛣ື 䛭䛾௚• FX100䛾䜸䞊䝞䝷䝑䝥ಁ㐍䛿⮬ື༊㛫䝰䞊䝗䜢౑⏝(--mca opal_progress_thread_mode 3)5

157 / 253

Copyright 2015 FUJITSU LIMITED㏻ಙ䜸䞊䝞䝷䝑䝥ຠᯝ䛾ホ౯(2/3)
 ㏻ಙ䝇䝺䝑䝗ᑐ䜰䝅䝇䝍䞁䝖䝁䜰䛾ຠᯝẚ㍑
䐟䝬䝇䝍䝇䝺䝑䝗䛾ᐇ⾜᫬㛫 䝭䝸⛊





䐠










༊㛫

 ༊㛫㏻ಙ䝇䝺䝑䝗ゎ㝖∧
㏻ಙಁ㐍䛒䜚㏻ಙ䝇䝺䝑䝗ゎ㝖∧    ∧ ∧  ∧

∧  ༊㛫 ༊㛫䛭䛾௚ὀ) ㏻ಙ䝇䝺䝑䝗ゎ㝖∧䛾kernel_p༊㛫᫬㛫䛿
unroll∧䛛䜙䛾᥎ᐃ䛻䜘䜛 䜰䝅䝇䝍䞁䝖䝁䜰䛾䜸䞊䝞䝷䝑䝥ಁ㐍ຠᯝ䛿䚸㏻ಙ䝇䝺䝑䝗᪉ᘧ䛸ྠ➼௨ୖ䐟䐟 ㏻ಙ䝇䝺䝑䝗ゎ㝖∧䛿䚸䜰䝅䝇䝍䞁䝖䝁䜰䛻䜘䜛㏻ಙಁ㐍䛷14%ᛶ⬟ྥୖ䐠
6


Copyright 2015 FUJITSU LIMITED㏻ಙ䜸䞊䝞䝷䝑䝥ຠᯝ䛾ホ౯(3/3)
 䝃䜲䜽䝹䜰䜹䜴䞁䝔䜱䞁䜾⤖ᯝ䛾ẚ㍑(kernel_p༊㛫) unroll+overlap∧⛊䢎䢏䢔䡡䡳䡨䡫䡸䡩䢇䢚䡸䢚䡬ᚅ䛱ᩚᩘ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱䝇䝖䜰ᚅ䛱ᩚᩘ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱ᩚᩘ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱

ᾋືᑠᩘⅬ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᩚᩘ₇⟬ᚅ䛱

ᾋືᑠᩘⅬ₇⟬ᚅ䛱ศᒱ࿨௧ᚅ䛱

࿨௧䝣䜵䝑䝏ᚅ䛱䝞䝸䜰ྠᮇᚅ䛱䛭䛾௚䛾ᚅ䛱

࿨௧䝁䝭䝑䝖 ࿨௧䝁䝭䝑䝖࿨௧䝁䝭䝑䝖

䝡䝆䞊᫬㛫䝡䝆䞊᫬㛫䝯䝰䝸䝡䝆䞊᫬㛫



• 䝬䝇䝍䝇䝺䝑䝗䛾₇⟬ᩘ䛿䜋䜌䝊䝻э䝬䝇䝍䝇䝺䝑䝗䛿㏻ಙฎ⌮䛻ᑓᛕ














































 ㏻ಙ䝇䝺䝑䝗ゎ㝖∧ͤ䢎䢏䢔䡡䡳䡨䡫䡸䡩䢇䢚䡸䢚䡬ᚅ䛱

⛊

䝇䝖䜰ᚅ䛱

ᩚᩘ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱ᩚᩘ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱

ᾋືᑠᩘⅬ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᩚᩘ₇⟬ᚅ䛱

ᾋືᑠᩘⅬ₇⟬ᚅ䛱ศᒱ࿨௧ᚅ䛱

࿨௧䝣䜵䝑䝏ᚅ䛱䝞䝸䜰ྠᮇᚅ䛱ᩚᩘ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱䛭䛾௚䛾ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱࿨௧䝁䝭䝑䝖 ࿨௧䝁䝭䝑䝖࿨௧䝁䝭䝑䝖

䝡䝆䞊᫬㛫䝡䝆䞊᫬㛫䝯䝰䝸䝡䝆䞊᫬㛫• ඲䝇䝺䝑䝗䛷₇⟬ᩘ䛿ྠ➼• 䝬䝇䝍䝇䝺䝑䝗䛿㏻ಙฎ⌮䜒ᐇ⾜









ͤ䛯䛰䛧kernel_p༊㛫䛾䝇䝺䝑䝗୪ิ䝹䞊䝥䛿㟼ⓗ䝇䜿䝆䝳䞊䝸䞁䜾






































 ㏻ಙ䝇䝺䝑䝗ゎ㝖∧ͤ(㏻ಙಁ㐍䛒䜚)• ඲䝇䝺䝑䝗䛷₇⟬ᩘ䛿ྠ➼⛊䢎䢏䢔䡡䡳䡨䡫䡸䡩䢇䢚䡸䢚䡬ᚅ䛱ᩚᩘ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱䝇䝖䜰ᚅ䛱ᩚᩘ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱ᩚᩘ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱

ᾋືᑠᩘⅬ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᩚᩘ₇⟬ᚅ䛱

ᾋືᑠᩘⅬ₇⟬ᚅ䛱ศᒱ࿨௧ᚅ䛱

࿨௧䝣䜵䝑䝏ᚅ䛱䝞䝸䜰ྠᮇᚅ䛱䛭䛾௚䛾ᚅ䛱

࿨௧䝁䝭䝑䝖 ࿨௧䝁䝭䝑䝖࿨௧䝁䝭䝑䝖

䝡䝆䞊᫬㛫䝡䝆䞊᫬㛫䝯䝰䝸䝡䝆䞊᫬㛫







• 䝬䝇䝍䝇䝺䝑䝗䛾㐜䜜䛿5%⛬ᗘ



䝇䝺䝑䝗ᩘ䛜2෢䚸ືⓗ䝇䜿䝆䝳䞊䝸䞁䜾୙せ䚸䝹䞊䝥୍㔜໬䜒୙せ






































7


158 / 253

Copyright 2015 FUJITSU LIMITED éĖýđÛÏÓã»4¯ÜU}@GKV䜹䞊䝛䝹䛻䛚䛡䜛䜸䞊䝞䝷䝑䝥ຠᯝ (1/4)
 ホ౯᮲௳
d. 䜸䞊䝞䝷䝑䝥䛒䜚 (MPI_Ialltoall)䛾䝁䞊䝗䜲䝯䞊䝆

ᐃ⎔ቃ:• FX100 16䝜䞊䝗 (2.2GHz䚸18.0Tflops)ᐃ᮲௳• ၥ㢟䝃䜲䝈: nxw㽢nyw䠙128㽢128䚸
global_nz㽢global_nv㽢global_nm
䠙16㽢16㽢15• ୪ิᩘ: 16䝇䝺䝑䝗㽢32䝥䝻䝉䝇䚸
nprocw㽢nprocz㽢nprocv㽢nprocm㽢nprocs
䠙4㽢2㽢2㽢2㽢1

 ౑⏝䝞䜲䝘䝸

!$OMP PARALLEL
do im = 2, nm-2!$OMP MASTERCALL MPI_Ialltoall!$OMP END MASTER!$OMP DO SCHEDULE(DYNAMIC)
do i = 1, num_trans
FFT₇⟬
enddo
!$OMP MASTERCALL MPI_Waitall!$OMP END MASTER!$OMP BARRIER
enddo!$OMP END PARALLELa. 䜸䞊䝞䝷䝑䝥䛺䛧 (MPI_Alltoall)b. 䜸䞊䝞䝷䝑䝥䛒䜚(MPI_Alltoall䠇OpenMP㏻ಙฎ⌮䝇䝺䝑䝗)c. 䜸䞊䝞䝷䝑䝥䛺䛧 (MPI_Ialltoall)ͤ
d. 䜸䞊䝞䝷䝑䝥䛒䜚 (MPI_Ialltoall)ͤ
e. 䜸䞊䝞䝷䝑䝥䛒䜚 (MPI_Ialltoall䠇㟼ⓗ䝇䝺䝑䝗䝇䜿䝆䝳䞊䝹)ͤ

ͤ:ᐩኈ㏻ഃ䛷సᡂ 䛭䛾௚• 䜸䞊䝞䝷䝑䝥ಁ㐍䛿⮬ື༊㛫䝰䞊䝗䜢౑⏝ (--mca opal_progress_thread_mode 3)8

159 / 253

Copyright 2015 FUJITSU LIMITEDGKV䜹䞊䝛䝹䛻䛚䛡䜛䜸䞊䝞䝷䝑䝥ຠᯝ (2/4)
ᐃ⤖ᯝ &) ! "

&(
&'

䐟

&

䐡

䐠

%*
%)
%(
%'
%

     !      !    " !    " !    + !   " + " !    "+    "+  !  "!  "! "! "

 MPI_Alltoall䠇OpenMP㏻ಙฎ⌮䝇䝺䝑䝗䛷䛿䚸35.4%䛾ᐇ⾜᫬㛫▷⦰䐟䐟 MPI_Ialltoall䠇䜰䝅䝇䝍䞁䝖䝁䜰᭷ຠ໬䛷䛿䚸34.7%䛾ᐇ⾜᫬㛫▷⦰䐠 䐠䛻ᑐ䛧㟼ⓗ䝇䝺䝑䝗䝇䜿䝆䝳䞊䝹䜢⾜䛖䛸䚸▷⦰ᖜ䛿26.5%䛻ῶᑡ䐡
9

Copyright 2015 FUJITSU LIMITED

GKV䜹䞊䝛䝹䛻䛚䛡䜛䜸䞊䝞䝷䝑䝥ຠᯝ (3/4)
 ㏻ಙฎ⌮᫬㛫▷⦰䛚䜘䜃䜸䞊䝞䝷䝑䝥ᗘྜ䛔䛾☜ㄆྛᐃ䛾᫬㛫ෆヂ䜢୪䜉᭰䛘䛯⤖ᯝ&) ! "&( 䜰䝅䝇䝍䞁䝖䝁䜰↓ຠ᫬䖩䖩䛿
MPI_Alltoall䛸MPI_Ialltoall䛜䜋䜌ྠ䛨ฎ⌮᫬㛫

&'
&
%*
%)

65%⛬ᗘ

%(
%'

• ᚋ⪅䛿Tofuྥ䛡䜰䝹䝂䝸䝈䝮䛷䛺䛔䛜䚸䝜䞊䝗ᩘ䛜ᑡ䛺䛔䛯䜑ᙳ㡪ᑠ%     !      !    " !    " !    + !   " + " !    "+    "+  䖩 䜰䝅䝇䝍䞁䝖䝁䜰䜢᭷ຠ䛻䛩䜛䛸䚸
MPI_Ialltoall䛿65%⛬ᗘ᫬㛫▷⦰!  "䖩! "䖩䖩!  "! "&) ! "&( 䐠MPI_Alltoall䠇OMP㏻ಙ䝇䝺䝑䝗䜔
䐡MPI_Ialltoall䠇䜰䝅䝇䝍䞁䝖䝁䜰䛷䛿䚸bwd䠇fwd༊㛫䛾⤒㐣᫬㛫䛜䐟䜸䞊䝞䝷䝑䝥䛺䛧᫬䛾₇⟬᫬㛫䛻ᴫ䛽୍⮴㏻ಙ᫬㛫䛾㞃䜊䛔䛻ᡂຌ

&'
&
%*
%)
%(
%'
%

     !      !    " !    " !    !   " + " !    "+  + 
  "+  䐟!  "10
160 / 253䐠! "䐡!  "! "

Copyright 2015 FUJITSU LIMITEDGKV䜹䞊䝛䝹䛻䛚䛡䜛䜸䞊䝞䝷䝑䝥ຠᯝ (4/4)
 䝃䜲䜽䝹䜰䜹䜴䞁䝔䜱䞁䜾⤖ᯝ䛾ẚ㍑(bwd:comm.+comp.༊㛫)䐟 䜸䞊䝞䝷䝑䝥䛺䛧 (MPI_Alltoall)䐟⛊䢎䢏䢔䡡䡳䡨䡫䡸䡩䢇䢚䡸䢚䡬ᚅ䛱ᩚᩘ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱䝇䝖䜰ᚅ䛱ᩚᩘ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱ᩚᩘ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᾋືᑠᩘⅬ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱

ᾋືᑠᩘⅬ䢗䡬䢀䢚䡭䡴䡺䡹ᚅ䛱

ᩚᩘ₇⟬ᚅ䛱

ᾋືᑠᩘⅬ₇⟬ᚅ䛱ศᒱ࿨௧ᚅ䛱

࿨௧䝣䜵䝑䝏ᚅ䛱䝞䝸䜰ྠᮇᚅ䛱䛭䛾௚䛾ᚅ䛱

࿨௧䝁䝭䝑䝖

࿨௧䝁䝭䝑䝖࿨௧䝁䝭䝑䝖

䝡䝆䞊᫬㛫䝡䝆䞊᫬㛫䝯䝰䝸䝡䝆䞊᫬㛫• 㠀䝬䝇䝍䝇䝺䝑䝗䛾䝞䝸䜰ྠᮇᚅ䛱኱









䐠 䜸䞊䝞䝷䝑䝥䛒䜚(MPI_Alltoall䠇OMP㏻ಙ䝇䝺䝑䝗)







⛊



• 䝞䝸䜰ྠᮇᚅ䛱䜢䜋䜌ゎᾘ























































































































䐠








䐡 䜸䞊䝞䝷䝑䝥䛒䜚 (MPI_Ialltoall)䠇䜰䝅䝇䝍䞁䝖䝁䜰







• 䝞䝸䜰ྠᮇᚅ䛱䜢䜋䜌ゎᾘ⛊



䐡






䐢 䜸䞊䝞䝷䝑䝥䛒䜚(MPI_Ialltoall䠇㟼ⓗ䡹䢖䡫䢀䢚䡹䡵䡸䢚䡩䡬䢕)䠇䜰䝅䝇䝍䞁䝖䝁䜰









⛊


• ྛ䝇䝺䝑䝗䛾₇⟬㔞䛜ྠ䛨䐢э㠀䝬䝇䝍䝇䝺䝑䝗䛻㏻ಙฎ⌮ᚅ䛱䛜Ⓨ⏕
⏕










௒ᅇ䜿䞊䝇䛿ືⓗ䝇䝺䝑䝗䝇䜿䝆䝳䞊䝹䛜᭷฼








11

Copyright 2015 FUJITSU LIMITED éĖýđÛÏÓã~ÜU}@161 / 253

GT5DéĖýđ
~]

35

ĊċĐåëõó]

32
K

6

FX100-1CMG

đĖāďæĔ[%]

28.4 

25.1

đĖāďæĔ[msec]

2.01

0.58

~U[%]

14.0

13.4

A

4.39

1.17

a·[msec]

ĊċĐĀĔüK [GB/s]
L1DĈó]

23.4

89.3

2.73e6

1.04e6

L1DĈódm[%]

43.4

24.8

6.44e5

3.14e5

8.9

37.4

SIMD1[%]

99.7

99.8

2SIMD~/SIMD~[%]

72.3

34.3

L2Ĉó]
L2Ĉódm[%]

ÇSTREAM Benchmark: K~46.6GB/s, FX100~310GB/sÇCompiler option
K:-Kfast -Kparallel,openmp -X9 -Kmfunc=2 -Kocl -CcdRR8-fw -Qt -Ntl_notrt-xpre_diff -Kfast -Kopenmp -Kocl,optmsg=2 -X9-Kmfunc=2 -Kloop_nofusion -CcdRR8-Kprefetch_sequential=soft,prefetch_cache_level=1

FX100:



real*8 f(-1:nv+2,-1:nz+2,-1:ny+2,-1:nx+2)
!$OMP DO SCHEDULE(dynamic)
do i = 1,nx (nx=32)
do j = 1,ny (ny=32)
compute vxyv~vxl2 from vx(l,j,i),vy(l,j,i),vz(l,j,i),vv(l,j,i)do k = 1,nz (nz=16)
do l = 1,nv (nv=128)
LOADdf(l,k,j,i)=
LOAD/STORE&
vxyv(l)*f(l,k,j,i)&+ vvr(l) *f(l+1,k,j,i)&- vvl(l) *f(l-1,k,j,i)&- vvr2(l)*f(l+2,k,j,i)&+ vvl2(l)*f(l-2,k,j,i)&+vzl2(l)*(f(l,k-2,j,i)-f(l,k+2,j,i))&+vzl(l) *(f(l,k+1,j,i)-f(l,k-1,j,i))&+ vyr(l) *f(l,k,j+1,i)&- vyl(l) *f(l,k,j-1,i)&- vyr2(l)*f(l,k,j+2,i)&+ vyl2(l)*f(l,k,j-2,i)&+ vxr(l) *f(l,k,j,i+1)&- vxl(l) *f(l,k,j,i-1)&- vxr2(l)*f(l,k,j,i+2)&+ vxl2(l)*f(l,k,j,i-2)
dfc=dfc+df(l,k,j,i)*fc(l,k,j,i)
enddo
enddo
enddo
enddo

đĖāďæĔÐâ9ÑÒU#&ÈU#&Ü)3ä¨lÔÖÎ21¦¨,ĝŋĲņæŏOnn
¥n

33

ĿŀŅĖğĨĦn

24
K

D

33.3 

29.7

ņŋķńĘŉ[msec]

1.62

0.46

¥b¯[%]

28.3

16.5

P²rÒ[msec]

1.91

0.83

ĿŀŅĴŉİX [GB/s]
L1DĽĦn
L1DĽĦdm[%]
L2ĽĦn
L2ĽĦdm[%]
SIMD8

[%]

9SIMD¥/SIMD¥[%]

FX100-1CMG

ņŋķńĘŉ[%]

38.9 

87.6

1.41e6

7.35e5

18.8

6.6

4.17e5

1.87e5

4.0

34.2

100.0

100.0

93.9

37.5

āĆņŋķńĘŉąŎ$ĂăĒąĄS÷éFX100āĆIXĄb¯(,L2ĽĦdmñÚóĸŅķĚĬīñíĉó¯÷Āìăìő

FMA¥ñóê.©ă 9ąĝŋĲņĕíĉó¸ÎāòĀìăìő

real*8 f(-1:nv+2,-1:nz+2,-1:ny+2,-1:nx+2)
!$OMP DO SCHEDULE(dynamic)
do i = 1,nx (nx=32)
do j = 1,ny (ny=32)
do k = 1,nz (nz=16)
do l = 1,nv (nv=128)
LOADdf(l,k,j,i)= &LOAD/STORE&
f(l,k,j,i) *1.11d0&+f(l-2,k,j,i) *1.12d0&+f(l-1,k,j,i) *1.13d0&+f(l+1,k,j,i) *1.14d0&+f(l+2,k,j,i) *1.15d0&+f(l,k-2,j,i) *1.16d0&+f(l,k-1,j,i) *1.17d0&+f(l,k+1,j,i) *1.18d0&+f(l,k+2,j,i) *1.19d0&+f(l,k,j-2,i) *1.21d0&+f(l,k,j-1,i) *1.22d0&+f(l,k,j+1,i) *1.23d0&+f(l,k,j+2,i) *1.24d0&+f(l,k,j,i-2) *1.25d0&+f(l,k,j,i-1) *1.26d0&+f(l,k,j,i+1) *1.27d0&+f(l,k,j,i+2) *1.28d0
enddo
enddo
enddo
enddo

5

162 / 253¦¨,ĝŋĲņçŏÍ
¥n

33

ĿŀŅĖğĨĦn

24
K

D

FX100-1CMG

ņŋķńĘŉ[%]

33.3 

29.7

ņŋķńĘŉ[msec]

1.62

0.46

¥b¯[%]

15.9

12.6

P²rÒ[msec]

3.40

1.09

ĿŀŅĴŉİX [GB/s]
L1DĽĦn
L1DĽĦdm[%]
L2ĽĦn
L2ĽĦdm[%]
SIMD8

[%]

9SIMD¥/SIMD¥[%]


n

21.6

72.3

2.54e6

7.75e5

30.0

25.2

4.11e5

2.10e5

5.0

17.0

100.0

100.0

94.0

37.4

āčIXĄb¯(,L1DĽĦnédmĂčĄIXĄE'ê
FX100āĆL1DĽĦnąEIĆìê

real*8 f(-1:nv+2,-1:nz+2,-1:ny+2,-1:nx+2)!$OMP DO SCHEDULE(dynamic)
do i = 1,nx (nx=32)
do j = 1,ny (ny=32)
do k = 1,nz (nz=16)
do l = 1,nv (nv=128)
LOADdf(l,k,j,i)= &LOAD/STORE&
vv_(l) *f(l,k,j,i)&+vvl2(l)*f(l-2,k,j,i)&-vvl(l) *f(l-1,k,j,i)&+vvr(l) *f(l+1,k,j,i)&-vvr2(l)*f(l+2,k,j,i)&+vzl2(l)*f(l,k-2,j,i)&-vzl(l) *f(l,k-1,j,i)&+vzr(l) *f(l,k+1,j,i)&-vzr2(l)*f(l,k+2,j,i)&+vyl2(l)*f(l,k,j-2,i)&-vyl(l) *f(l,k,j-1,i)&+vyr(l) *f(l,k,j+1,i)&-vyr2(l)*f(l,k,j+2,i)&+vxl2(l)*f(l,k,j,i-2)&-vxl(l) *f(l,k,j,i-1)&+vxr(l) *f(l,k,j,i+1)&-vxr2(l)*f(l,k,j,i+2)
enddo
enddo
enddo
enddo

Cf. L1DĽĦ¿·K:
8B×10¶ª×(128×16×32×32)<À÷128B/$ńĘŉŐ1.31e6
FX100:8B×10¶ª×(128×16×32×32)<À÷256B/$ńĘŉŐ6.55e5
äl-2~l+2,k-1~k+1ĕĜŉL1$ĂkO6 ÛÏÓã1Ü)3

163 / 253ૼ୒ੲਾ भ ৲૗஄્ඉy ৲૨ऋৈःy୵ഥभధഔਙऋ଩ः‫ق‬౰઴ॶজ‫ش‬ऋৈः‫ك‬ yଂਚ৓ऩ୵ഥ५ॣ४গ‫ش‬জথॢभ஍ટൠy९ইॺक़ख़॔ঃॖউছॖথॽথॢऋથ஍ध
ਖ਼૵खञৃ়प৭උ



૗஄୻







          










䠖 ࿨௧
7

Copyright 2016 FUJITSU LIMITEDૼ୒ੲਾ 
भధഔ৲૗஄્ඉy ৲૨ऋ଩ःy୵ഥभధഔਙऋৈः‫ق‬౰઴ॶজ‫ش‬ऋ଩ः‫ك‬yଂਚ৓ऩ୵ഥ५ॣ४গ‫ش‬জথॢभ஍ટৈ y९ইॺक़ख़॔ঃॖউছॖথॽথॢऋൠःध
ਖ਼૵खञৃ়प৭උ

૗஄୻





          
















䠖 ࿨௧
8

164 / 253

Copyright 2016 FUJITSU LIMITEDৌ଴॥‫ ॻش‬㏣ຍਫ਼઒॥‫ॻش‬ड़জ४ॼঝ॥‫ॻش‬भঝ‫ش‬উ঎ॹॕभ१ॖ६॑૗৲
॥‫ ॻش‬ࠥGI ͐ 
ࠥࠥ͐
 
 ࠥࠥ͐
 
 
 
 
ࠥ

 

ࠥ
 ͐ 
 
 
 
 
 
 
  ࠥ॥‫ ॻش‬    


 
 

॥‫ ॻش‬         ࠥ͐
 
 
 
 
 
 
 
 
 
   
ࠥ

 
 
 
 

॥‫ ॻش‬                


 
 
 
 
 
 
 
 

॥‫ ॻش‬                        


3

 
 
 
 
 
 
 
 
 
 
 
 

Copyright 2016 FUJITSU LIMITED৹ਪ੥ટ  ኚ᭦॥‫ॻش‬ถ಍উটই॓ॖছ
⛊


ड़জ४ॼঝ

യਤ

ӖӗӜҩһҰҳӀұӏӢӀӢҴୄठତਯট‫ॻش‬ওঔজ॔ॡ७५ୄठ
೟৿৵ਯਡট‫ॻش‬ওঔজ॔ॡ७५ୄठ
५ॺ॔ୄठତਯট‫॔ ॻش‬ॡ७५ୄठ
ତਯӟҴӈӢ ҵҼӂӁୄठ೟৿৵ਯਡট‫॔ ॻش‬ॡ७५ୄठ
೟৿৵ਯਡӟҴӈӢ ҵҼӂӁୄठତਯ౰઴ୄठ
೟৿৵ਯਡ౰઴ୄठ
ীว୵ഥୄठ
୵ഥইख़ॵॳୄठ
ংজ॔৊਋ୄठ
जभ౎भୄठ
୵ഥ॥঑ॵॺ ୵ഥ॥঑ॵॺ
୵ഥ॥঑ॵॺ

 










౰઴
আ‫ش‬ॡૻ

୵ഥ૨ 
୵ഥ૨

ӖӗӜӁӝҴӐӣҳӈ 

੕୵ഥਯ

ड़জ४ॼঝ

   

 

യਤ

 

   

 

 

    5

165 / 253

Copyright 2016 FUJITSU LIMITED৹ਪ੥ટ ㏣ຍ৸৬ॹ‫ॱش‬
⛊








䢎䢏䢔䡡䡳䡨䡫䡸䡩䢇䢚䡸䢚䡬ᚅ䛱ᩚᩘ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱
ᾋືᑠᩘⅬ䝻䞊䝗䝯䝰䝸䜰䜽䝉䝇ᚅ䛱䝇䝖䜰ᚅ䛱ᩚᩘ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱ᩚᩘ䢗䡬䢀䢚 䡭䡴䡺䡹ᚅ䛱
ᾋືᑠᩘⅬ䝻䞊䝗䜰䜽䝉䝇ᚅ䛱
ᾋືᑠᩘⅬ䢗䡬䢀䢚 䡭䡴䡺䡹ᚅ䛱
ᩚᩘ₇⟬ᚅ䛱
ᾋືᑠᩘⅬ₇⟬ᚅ䛱ศᒱ࿨௧ᚅ䛱
࿨௧䝣䜵䝑䝏ᚅ䛱䝞䝸䜰ྠᮇᚅ䛱䛭䛾௚䛾ᚅ䛱
࿨௧䝁䝭䝑䝖
࿨௧䝁䝭䝑䝖࿨௧䝁䝭䝑䝖

䜸䝸䝆䝘䝹  ಁ㐍 䜸䝸䝆䝘䝹  ಁ㐍 䜸䝸䝆䝘䝹  ಁ㐍 䜸䝸䝆䝘䝹  ಁ㐍 䜸䝸䝆䝘䝹  ಁ㐍



6

Copyright 2016 FUJITSU LIMITEDßÚàn,ăďôć|£jïĖüÜ
tÜd$Uäp¥ÔÖÊ¡¤éĖýđäCªÚÔØFX100Ü_åñóöĔûïåäÎÖ¯Ú~ÜèĖĀĖďøă
 cE¸ÜïĖü8bÙRiÜ¯ćóëXzÚ.LÜ$k§¿
 MPI«%ÐâåñóöĔûïåÞÜßÙÜèĖĀĖĄøü
 ½.f»4¯ÞÜTofuDåđðĐôĉ³~
 L1êČøñčO&Ûá×ØË
ÌÜNÙÍ×ÖL1êČøñč,ä£x§¿
FMA1Ü0ăĐāçø÷$Ü0

30

166 / 253

2.9 生体分子粗視化シミュレータ CafeMol の FX100 での性能評価
理化学研究所

情報基盤センター
検崎博生

2.9.1 はじめに
CafeMol は生体分子の粗視化シミュレータで、タンパク質や核酸のダイナミクスを調べることができる。生体分子である、タンパク質、核酸、脂質は分子レベルの生体機能を担うが、多くの生体分子は構造変化することによってさまざまな機能を実現する。粗視化モ
デルでは、全原子シミュレーションでは再現することが難しいような大規模な構造変化を簡単に計算することができる。また、CafeMol の特徴はタンパク質や核酸の構造変化のシ
ミュレーションを簡単に行えるところにある。
CafeMol で用いる粗視化モデルでは全原子モデルに比べて粒子数が 10 分の 1 程度に減り、水分子もあらわに扱わないので粒子数が少数ですむ。結果として、計算量をかなり減らすことができるのであるが、これは並列性能を出しにくいということにも繋がっている。一
方、今後の計算機の発展を考えると、ノード内のコアの数がますます増えると予想される
ので、CafeMol でも 1 ノード内での並列性能を上げることが重大な問題になっている。
2.9.2 プログラム概要
分子動力学シミュレーションでは、分子の動きを時間積分することにより系を時間発展させるわけであるが、時間積分のステップを進める際の分子間に働く力の計算が最も時間が掛かる部分となっている。CafeMol では力の計算にネイバリングリスト方式を用いて計算量を減らしており、MPI と OpenMPI によるハイブリッド並列化を行っている。
粗視化された粒子間に働く相互作用はさまざまなものがあり、相互作用毎に異なるチューニングが必要になってくる。タンパク質の粗視化モデルでは比較的近距離の相互作用だ
けなのでステップ当たりの計算量は少なく、核酸では電荷の寄与が大きく遠距離の静電相互作用が必須で時間ステップ当たりの計算量は比較的多くなる。ここではタンパク質/DNA複合体であるヌクレオソームを対象に性能測定を行う。静電相互作用はデバイヒュッケル
理論に基づく近似を用いるため、イオン濃度が静電相互作用の到達距離を決める重要なパラメータとなっているが、ここでは生理条件と大きく変わらない 100mM で測定を行う。
なお、ヌクレオソームは粗視化粒子数が 2,000 程度の系で、CafeMol を使って行われている粗視化シミュレーションでは中程度の大きさの系となっている。
2.9.3 測定環境
性能測定には、理化学研究所の RICC システム(Intel Xeon)、SCLS 計算機システム(FX10)、
HOKUSAI システム(FX100)を使用した。それぞれの環境における CPU とコンパイラとデフォルトで用いたコンパイルオプションは以下の通りである。
Intel Xeon：Intel Xeon X5570(2.93GHz)、インテルコンパイラ、-O3

167 / 253



FX10：SPARC64TMIXfx(1.65GHz)、富士通コンパイラ、-Kfast



FX100：SPARC64TMXIfx(1.975H)、富士通コンパイラ、-Kfast

2.9.4 測定結果
性能測定は、ヌクレオソームの 10,000step の計算時間を測定した。まず、MPI 並列は用
いずに、OpenMP によるスレッド並列を用いた測定を行った。Xeon の 1 ノード 8 コアでの計算時間は 8.33 秒であり、FX10 での 1 ノード 16 コアでの計算時間は 15.5 秒、FX100での 1 ノード 16 コアで 9.9 秒、32 コアで 8.19 秒であった。FX100 は FX10 と比べると同じ 16 コアで 1.5 倍程度、倍の 32 コアでは 1.9 倍程度速くなっており、FLOPS 比には足りないが悪くない性能向上となっている。ただし、Xeon と比べると 4 倍の 32 コアでわずかに速くなっている程度なので、このままでは物足りない数字となっている。
次に、FX100 で 1 ノード 32 コアを固定して、MPI 並列と OpenMP のハイブリッド並列の測定を行った。2MPI/16 スレッド並列では 6.93 秒と 1MPI/32 スレッド並列の 8.19 秒よりも速くなった。4MPI/8 スレッド並列と 8MPI/4 スレッド並列でも 2MPI/16 スレッド並列と同程度速くなったので、以下では 2MPI/16 スレッド並列で測定を行った。
最 適化 オプシ ョン の効果 を調 べるた めに いくつ かの 最適化 オプ ション を試 し た 結
果、”-Kvisimpact”を使うと 6.06 秒まで速くなり、自動並列化”-Kparallel”の効果であると考えられる。それ以外の最適化オプションは効果がなかった。
次に、チューニングを行うために計算時間の内訳を見ると、力の計算に 2.96 秒、乱数に0.61 秒、ネイバリングリストの計算に 1.19 秒掛かっていた。全体の半分程度の時間が掛かっている力の計算については、以下で示すようにチューニングを試みた。なお、乱数については、組み込み関数を使うことで劇的な速度向上が見込まれる。
力の計算の内訳を見ると、もともと計算量が圧倒的に多い静電相互作用については SIMD化によるチューニングが既にされていることもあり 0.38 秒しか掛かっておらず、SIMD 化
されていない他の力の計算に時間が掛かっていた。
一般的に、分子動力学計算の力の計算では作用反作用の法則が成り立つため、SIMD 化が困難になる事情がある。例えば、2 体の相互作用を計算する際には 2 重ループを作って計算するが、外側のループ変数に依存する粒子 1 と内側のループ変数に依存する粒子 2 の力を計算した際、粒子 1 に掛かる力だけではなく粒子 2 に掛かる力も同時に計算できるのでこれを保存する必要があるが、そのままでは SIMD 化ができなくなる。ここで、粒子 2 に掛かる力を保存せずに捨てて、2 倍の量の計算を行うように変更するのが SIMD 化の 1 つ方法である。この方法では計算量が 2 倍になるというデメリットがあるが、静電相互作用の計算ではかなり性能が向上する。ところが、静電相互作用以外の相互作用では内側ループ長が短いためか、同程度か遅くなってしまう。3 体以上の相互作用では、この方法はさらに難しくなる。他にも SIMD 化するためのいくつかの方法で試したが、効果がないかむし
ろ遅くなった。

168 / 253

ここでは計算された力の保存が原因で SIMD 化が困難だったわけだが、アトミック操作などにより SIMD 化が可能になれば、性能が向上する可能性があると予想する。
2.9.5 まとめ
CafeMol を FX100 上で性能測定を行い、ハイブリッド並列におけるスレッド並列数やコ
ンパイルオプションの影響を調べ、最後にチューニングを試みた。FX100 では FX10 に比べると性能が予想よりも向上していたが、Xeon と比べると少し物足りないものとなった。
MPI と OpenMP のハイブリッド並列を行う際には、スレッド並列数 32 は性能が悪くなり、
4,8,16 スレッド並列の方がいい性能が得られた。また、自動並列化”parallel”により少し性能が向上することを確認した。チューニングに関しては、静電相互作用以外の相互作用の力の計算では SIMD 化が困難もしくは性能向上ができなった。最後に、アトミック操作がハードウェアもしくはソフトウェアで対応すればより SIMD 化が容易に行えるようになり、
チューニングに手数をあまり掛けなくても多くのアプリケーションで性能向上が実現できるのではないかと考える。

169 / 253

生体分子粗視化シミュレータCafeMol
FX100でのチューニング

検崎博生
理研 情報基盤センター

CafeMol (www.cafemol.org)
CafeMol 2.1 (2013/7)
source & manual released• Features are;–Various CG models–protein/DNA/RNA–multiple basin model–accurate CG model–Simulating protein‐at‐work–“switching”• Under development
lipid• Developer
検崎博生、古賀信康、藤原慎司、堀直人、金田亮、李 文飛、岡崎圭一、姚 新
秋、寺川剛、伊藤真志保、高田彰二
京都大学高田研究室
170 / 253

Coarse‐grained simulation
Reducing the number of particles to 1/100• 1 amino acid residue →1 particle (Catom)• No water molecule(included in potential energy)
Protein folding andfunctional conformational changecoarsegrained

10^6 times speed up• Reducing the number of particles• Enlarge time step
• Low friction

AA: 100PC 1week

CG: 1PC 1minute!!

計算規模と並列化• 計算規模• 数十から数万粒子数程度• 測定対象• ヌクレオソーム1個の系：1,854粒子• タンパク質/DNA複合体• 並列化• 系の時間発展をMPIとOpenMPでハイブリッド並列化• 数十並列程度の並列化• 力の計算はネイバリングリスト方式• レプリカ交換によるMPI並列• 通信量が少ないので大規模並列化• 平衡量を求める計算に使える
ネイバリングリストの例 (2体の相互作用、i<jだけをリストアップ)
i

1

j

2

2
4

7

9

5

3
8

4

4
5

9

7

5
8

6

171 / 253

6
7

9

8

7
9

8

8
9

9

ネイバリングリスト• 力場はネイバリングリスト方式で計算• 100stepに1回程度計算• ネイバリングリストはノード毎に分割• 最も大きな配列(粒子数x100～10,000)• 相互作用の到達範囲毎にネイバリングリストを作成• ローカルな相互作用• ボンド長、ボンド角、二面角• あらかじめネイバリングリスト作成しておく• 近距離相互作用(<20A)• 郷ポテンシャル、排除体積、塩基対• 中距離相互作用(20‐50A)• 疎水相互作用• 多体のため複雑なネイバリングリストに• 遠距離相互作用(>50A)• 静電相互作用• 塩濃度により相互作用距離が変化

RICCでの性能測定 Intel Xeon5570(2.93Hz)
nucleosome (104step, 100mM)
1threads
%
41.68

88.3

2threads
%
21.79

85.8

4threads
%
11.18

81.5

6.23

74.8

_force(comm)

0.16

0.3

0.16

0.6

0.26

1.9

0.54

6.5

_force(local)

4.85

10.3

2.53

10.0

1.30

9.4

0.69

8.2

force

8threads%_force(go)

1.26

2.7

0.65

2.6

0.32

2.4

0.17

2.1

_force(pnl)

14.63

31.0

7.11

28.0

3.54

25.8

1.77

21.3

_force(ele)

20.67

43.8

10.87

42.8

5.41

39.4

2.72

32.7

random

2.94

6.2

1.61

6.3

0.88

6.4

0.55

6.6

_random(comm)

0.04

0.1

0.04

0.2

0.05

0.4

0.07

0.8

neighbor

1.30

2.8

1.12

4.4

0.87

6.3

0.74

8.8

_neighbor(comm)

0.00

0.0

0.00

0.0

0.00

0.0

0.00

0.0

_neighbor(pnl)

1.14

2.4

0.97

3.8

0.71

5.2

0.58

6.9

_neighbor(ele)

0.11

0.2

0.11

0.4

0.11

0.8

0.11

1.3

_neighbor(solv)

0.05

0.1

0.05

0.2

0.05

0.4

0.05

0.6

update

0.43

0.9

0.35

1.4

0.35

2.6

0.41

4.9

copyxyz

0.01

0.0

0.00

0.0

0.00

0.0

0.00

0.0

energy

0.38

0.8

0.20

0.8

0.11

0.8

0.07

0.8

_energy(comm)

0.00

0.0

0.00

0.0

0.00

0.0

0.01

0.1

output

0.26

0.6

0.25

1.0

0.25

1.8

0.25

3.0

radiusg_rmsd

0.02

0.0

0.02

0.1

0.02

0.1

0.02

0.2

others

0.05

0.1

0.03

0.1

0.03

0.2

0.03

0.3

ope

47.03

99.6

25.19

99.2

13.41

97.7

7.72

92.7

comm

0.20

0.4

0.21

0.8

0.31

2.3

0.61

7.3

main_loop

47.23

100.0

25.40

100.0

13.72

100.0

8.33

100.0

172 / 253

FX10での性能測定(‐Kfast)
nucleosome (104step, 100mM)
1threads
%
86.64

80.8

2threads
%
46.35

75.8

4threads
%
23.45

68.9

8threads
%
12.9

61.3

16threads %
8.5

54.8

_force(comm)

0.20

0.2

0.33

0.5

0.57

1.7

1.1

5.1

2.1

13.6

_force(local)

11.47

10.7

5.82

9.5

3.00

8.8

1.6

7.5

0.9

5.7

_force(go)

5.50

5.1

2.79

4.6

1.46

4.3

0.7

3.5

0.4

2.5

force

_force(pnl)

50.36

47.0

24.77

40.5

12.23

35.9

6.2

29.2

3.1

20.1

_force(ele)

18.81

17.5

12.34

20.2

5.89

17.3

3.1

14.5

1.7

11.0

random

7.90

7.4

4.24

6.9

2.37

7.0

1.4

6.7

1.0

6.2

_random(comm)

0.14

0.1

0.14

0.2

0.14

0.4

0.1

0.7

0.1

0.9
23.7

neighbor

9.46

8.8

7.76

12.7

5.68

16.7

4.3

20.5

3.7

_neighbor(comm)

0.00

0.0

0.00

0.0

0.00

0.0

0.0

0.0

0.0

0.0

_neighbor(pnl)

8.39

7.8

6.68

10.9

4.59

13.5

3.2

15.4

2.6

16.7

_neighbor(ele)

1.50

1.4

1.52

2.5

1.53

4.5

1.5

7.1

1.5

9.7

_neighbor(solv)

0.30

0.3

0.29

0.5

0.30

0.9

0.3

1.4

0.3

1.9

update

0.83

0.8

0.82

1.3

0.83

2.4

0.8

3.9

0.8

5.4

copyxyz

0.14

0.1

0.14

0.2

0.14

0.4

0.1

0.7

0.1

0.9

energy

0.98

0.9

0.55

0.9

0.30

0.9

0.2

0.8

0.1

0.8

_energy(comm)

0.00

0.0

0.00

0.0

0.01

0.0

0.0

0.1

0.0

0.2

output

0.68

0.6

0.68

1.1

0.68

2.0

0.7

3.2

0.7

4.4

radiusg_rmsd

0.04

0.0

0.04

0.1

0.04

0.1

0.0

0.2

0.0

0.3

others

0.10

0.1

0.10

0.2

0.10

0.3

0.1

0.5

0.1

0.6

ope

106.91

99.7

60.67

99.2

33.34

97.9

19.8

94.2

13.2

85.3

comm

0.33

0.3

0.48

0.8

0.72

2.1

1.2

5.8

2.3

14.7

107.25

100.0

61.15

100.0

34.06

100.0

21.1

100.0

15.5

100.0

main_loop

FX100での予備的な性能測定(‐Kfast)
nucleosome (104step, 100mM)
1threads %
58.52

79.0

2threads %
29.78

73.1

4threads %
15.28

66.6

8.2

56.9

16threads %
4.8

48.9

32threads %
3.70

45.2

_force(comm)

0.11

0.2

0.16

0.4

0.25

1.1

0.4

3.0

0.8

7.8

1.45

17.7

_force(local)

8.90

12.0

4.51

11.1

2.30

10.0

1.2

8.4

0.6

6.5

0.36

4.5

_force(go)

4.20

5.7

2.14

5.3

1.10

4.8

0.6

3.9

0.3

3.0

0.16

1.9

_force(pnl)

36.06

48.7

17.41

42.7

8.71

38.0

4.4

30.5

2.2

22.4

1.14

13.9

_force(ele)

9.02

12.2

5.33

13.1

2.69

11.7

1.4

9.5

0.7

6.9

0.36

4.4

random

6.23

8.4

3.23

7.9

1.73

7.6

1.4

9.7

0.8

8.1

0.50

6.2

force

8threads%_random(comm)

0.06

0.1

0.06

0.1

0.06

0.3

0.1

0.4

0.1

0.7

0.06

0.7

neighbor

7.27

9.8

5.95

14.6

4.31

18.8

3.3

22.7

2.7

27.6

2.38

29.0

_neighbor(comm)

0.00

0.0

0.00

0.0

0.00

0.0

0.0

0.0

0.0

0.0

0.00

0.0

_neighbor(pnl)

6.54

8.8

5.21

12.8

3.58

15.6

2.5

17.7

2.0

20.4

1.64

20.1

_neighbor(ele)

0.94

1.3

0.96

2.3

0.94

4.1

0.9

6.5

0.9

9.3

0.95

11.6

_neighbor(solv)

0.24

0.3

0.24

0.6

0.24

1.0

0.2

1.7

0.2

2.4

0.24

2.9

update

0.51

0.7

0.51

1.3

0.51

2.2

0.5

3.6

0.5

5.4

0.63

7.6

copyxyz

0.08

0.1

0.08

0.2

0.08

0.4

0.1

0.6

0.1

0.9

0.09

1.1

energy

0.68

0.9

0.38

0.9

0.20

0.9

0.1

0.8

0.1

0.8

0.07

0.9

_energy(comm)

0.00

0.0

0.00

0.0

0.00

0.0

0.0

0.0

0.0

0.1

0.02

0.2

output

0.35

0.5

0.35

0.9

0.35

1.5

0.4

2.4

0.4

3.6

0.35

4.3

radiusg_rmsd

0.02

0.0

0.02

0.0

0.02

0.1

0.0

0.1

0.0

0.2

0.02

0.2

others

0.08

0.1

0.08

0.2

0.08

0.3

0.1

0.5

0.1

0.8

0.08

0.9

ope

73.92

99.8

40.52

99.5

22.63

98.6

13.9

96.6

9.0

91.5

6.66

81.4

comm

0.17

0.2

0.22

0.6

0.31

1.4

0.5

3.5

0.8

8.5

1.52

18.6

main_loop

74.10

100.0

40.75

100.0

22.94

100.0

14.4

100.0

9.9

100.0

8.19

100.0

173 / 253

FX100でスレッド数を変えた時の性能測定(‐Kfast)
nucleosome (104step, 100mM)
ノード内はMPI(32/nプロセス) x openMP(nスレッド)並列

スレッド数が4,8,16のときに高い性能

FX100でノード数を変えた時の性能測定(‐Kfast)
nucleosome (104step, 100mM)
ノード内はMPI(2プロセス) x openMP(16スレッド)並列

1ノードを超える並列性能は低い
174 / 253

FX100で最適化オプションを変えた時の性能測定
nucleosome (104step, 100mM)
ノード内はMPI(2プロセス) x openMP(16スレッド)並列
京で推奨されていた最適化オプションを使用(opt_kei)-V –Kvisimpact,ocl,preex,array_private,auto,openmp,optmsg=2,simd=2 -Qt
fast
force
_force(comm)_force(local)_force(go)_force(pnl)_force(ele)random_random(comm)neighbor_neighbor(comm)_neighbor(pnl)_neighbor(ele)_neighbor(solv)
updatecopyxyzenergy_energy(comm)outputradiusg_rmsd
othersope
commmain_loop

%
3.44
1.10
0.37
0.16
1.14
0.37
0.62
0.06
1.39
0.00
1.02
0.47
0.12
0.53
0.09
0.06
0.02
0.34
0.02
0.08
5.74
1.18
6.93

opt_kei
49.59
15.92
5.35
2.31
16.45
5.38
8.89
0.93
20.07
0.00
14.67
6.76
1.74
7.71
1.26
0.94
0.22
4.86
0.24
1.10
82.93
17.07
100.00

%
2.96
0.61
0.37
0.16
1.14
0.38
0.61
0.06
1.19
0.00
1.00
0.09
0.12
0.33
0.09
0.06
0.01
0.35
0.03
0.08
5.38
0.68
6.06

48.87
10.00
6.10
2.65
18.89
6.19
10.11
1.06
19.58
0.00
16.44
1.52
2.06
5.38
1.50
0.95
0.15
5.71
0.50
1.26
88.79
11.21
100.00効果があったオプションは、fast→visimpact、つまりparallelの効果

チューニングの方針•

force• eleはすでにSIMD化• localは、2-4体の相互作用••

opt_kei•••

ボンド長：i,i+1
ボンド角：i,i+1,i+2
二面角：i,i+1,i+2,i+3•

pnlはネイバリングリスト自体は1つだがさまざ
まな力で分割して利用

goとpnlは基本2体だが、ネイバリングリストから変更する必要がある?

random• 組み込み関数を使えば速くなる見込み

175 / 253

force
_force(comm)_force(local)_force(go)_force(pnl)_force(ele)random_random(comm)neighbor_neighbor(comm)_neighbor(pnl)_neighbor(ele)_neighbor(solv)
updatecopyxyzenergy_energy(comm)outputradiusg_rmsd
othersope
commmain_loop

%
2.96
0.61
0.37
0.16
1.14
0.38
0.61
0.06
1.19
0.00
1.00
0.09
0.12
0.33
0.09
0.06
0.01
0.35
0.03
0.08
5.38
0.68
6.06

48.87
10.00
6.10
2.65
18.89
6.19
10.11
1.06
19.58
0.00
16.44
1.52
2.06
5.38
1.50
0.95
0.15
5.71
0.50
1.26
88.79
11.21
100.00ローカルな力のチューニング






 K  1  cos     K  1  cos 3   

Vlocal  K b  ri ,i1  r0 i ,i 1  K   i   0 i
2

i

2

i

1

3



i



0i

i

i

0i

i

ボンド長：2体
ボンド角：3体
二面角：4体ボンド長の力の計算のソースコード

imp1!$omp do private(imp1,imp2,v21,dist,ddist,ddist2,for, &!$omp&

force,efull,iunit,junit,isys,istat)do ibd = ksta, kend
imp1 = ibd2mp(1, ibd)
imp2 = ibd2mp(2, ibd)v21(1:3) = xyz_mp_rep(1:3, imp2,irep) - xyz_mp_rep(1:3, imp1,irep)
dist = sqrt(v21(1)**2 + v21(2)**2 + v21(3)**2)
ddist = dist - bd_nat(ibd)ddist2 = ddist**2
for = (coef_bd(1, ibd) + 2.0e0_PREC * coef_bd(2, ibd) * ddist2) * &(-2.0e0_PREC * ddist / dist)
force(1:3) = for * v21(1:3)
force_mp(1:3, imp1) = force_mp(1:3, imp1) - force(1:3)
force_mp(1:3, imp2) = force_mp(1:3, imp2) + force(1:3)
end do!$omp end do nowait
176 / 253

ibd

imp2

ボンド長の力の計算のlstファイル

imp1
ibd

imp2

<<< Loop-information Start >>><<< [OPTIMIZATION]<<<

FULL UNROLLING<<< Loop-information End >>>64

1 p 6v

force(1:3) = for * v21(1:3)

65

1

66

1 p 6sforce_mp(1:3, imp1) = force_mp(1:3, imp1) - force(1:3)

67

1 p 6mforce_mp(1:3, imp2) = force_mp(1:3, imp2) + force(1:3)

68
69

1 p 2vend do!$omp end do nowait

排除体積相互作用の力の計算のソースコード!$omp do private(imp1,imp2,v21,dist2,&!$omp&
roverdist2,roverdist4, &!$omp&
roverdist8,roverdist14,dvdw_dr,for)
do ipnl=ksta, kend
imp1 = ipnl2mp(1, ipnl, irep)
imp2 = ipnl2mp(2, ipnl, irep)v21(1:3) = xyz_mp_rep(1:3, imp2, irep) - xyz_mp_rep(1:3, imp1, irep)
dist2 = v21(1)**2 + v21(2)**2 + v21(3)**2
if(dist2 > cutoff2) cycle
roverdist2 = cdist2 / dist2
roverdist4 = roverdist2 * roverdist2
roverdist8 = roverdist4 * roverdist4
roverdist14 = roverdist2 * roverdist4 * roverdist8
dvdw_dr = coef * roverdist14
if(dvdw_dr > DE_MAX) dvdw_dr = DE_MAX
for(1:3) = dvdw_dr * v21(1:3)
force_mp(1:3, imp2) = force_mp(1:3, imp2) + for(1:3)
force_mp(1:3, imp1) = force_mp(1:3, imp1) - for(1:3)
end do!$omp end do nowait
177 / 253

排除体積相互作用の力の計算のｌｓｔファイル

62

1<<< Loop-information Start >>><<< [OPTIMIZATION]<<<

FULL UNROLLING<<< Loop-information End >>>63

1 p 6mfor(1:3) = dvdw_dr * v21(1:3)

64

1 p 6sforce_mp(1:3, imp2) = force_mp(1:3, imp2) + for(1:3)

65

1 p 6mforce_mp(1:3, imp1) = force_mp(1:3, imp1) - for(1:3)

66

1 p 2v67

end do!$omp end do nowait

まとめ• FX100でのベンチマーク結果• 同じ16コアでFX10に比べて1.5倍程度性能向上• 4,8,16スレッド並列で性能が出た• 自動並列化オプションが効果的だった• FX100でのチューニングの方針• 力の計算• 静電相互作用以外でSIMD化用のコード作成• 結果として、チューニングは上手くいかなかった• 変数iのループで引数iだけでなく引数jの配列に計算結果を保存するときにもSIMD化ができるようにならないだろうか？
• 変数kのループで引数i, jの配列に計算結果を保存するときにもSIMD化ができるようにならないだろうか？

178 / 253

2.10 N 体計算ベンチマーク
理化学研究所

計算科学研究機構
似鳥 啓吾

2015/3/17 の第 5 回と 2015/7/1 の第 6 回の WG とで報告を行った。PowerPoint の資料
は発表時のものをそのまま掲載する。立て続けに発表することになった経緯は、第 5 回の終わりに次回発表者を決める際に、似鳥がうっかりと「次回までに FX100 を触っていることになっている人にしよう」などと発言したためである。発表したのは Hermite 積分法による N 体計算ベンチマークコード(github.com/nitadori/Hermite)とその結果である。最初は AVX と HPC-ACE の間で SIMD マルチコアな CPU の単体性能を比較しようというぐらいのつもりで書き始めたコードだったのだが、その後の拡張により最近では
Xeon-Phi KNC、CUDA (Kepler)、AVX2、HPC-ACE2 にも対応している。GPU 対応について
は、メモリ空間が分断されていることと倍精度の高速なものは高価だったことから当初は乗り気ではなかったのだが、2014 年秋の科学技術計算分科会でのパネルディスカッションで MIC との比較を行うことになった機会に実装したものである。
第 5 回の WG ではコードの概要説明と HPC-ACE 向け実装について報告した。発表資料には一点間違いがあり、ベンチマークで使用した FX10 は 1.85 GHz のものではなく実は1.65 GHz であった。対ピーク性能比に対して 1 割強の過小評価をしていたことになる。
HPC-ACE 用の実装で苦労した点は、C++での記述から十分に最適化されたコードを得ることである。筆者は 2012 年秋の科学技術計算分科会のパネルで、簡単なクラスや構造体に対してなかなか思ったようなコードが得られない（変数がレジスタに乗らずにメモ
リアクセスになる）とクレームを付けていたのだが、この頃と比べると Fujitsu コンパ
イラの C++最適化は劇的に改善されており、ある程度気をつけて（ほぼ自明なコピーコ
ンストラクタや代入演算子も忘れずに定義することなど）書けば変数が全てレジスタに乗るような理想的なコードが出力されることが確認できた。実際のベンチマーク結果であるが、粒子数が少ない領域での性能低下が若干気にはなるもののおおむねピーク性能の 2/3 程度は出ており、積和算ではない演算もそれなりに含まれていることを考えれば十分な最適化がなされたコードといえる。富士通製品のチューニングの話題からは離れるが、Xeon Phi の小粒子数領域での性能低下は相当に深刻なものである。筆者のチューニングが不十分という可能性もあるのかもしれないが（少なくとも手を抜いたつもりはないのだが）、ホスト CPU からの明示的なデータコピーとカーネル呼び出しを含む
CUDA 版の実装以上に小粒子数での同期オーバーヘッドが発生していることがわかる。
第 6 回の WG では、
新規にアクセス可能になった理研和光の FX100 及び 16 コアの Xeon

179 / 253

E5 v3 (Haswell)でのベンチマーク結果を報告した。前回からのコード改善点として、OpenMP による並列化の部分で必要以上の同期やパラレルスコープの開閉が含まれていた部分が修正されている。この変更でどのアーキテクチャでも粒子数の小さな領域での効率が改善された。FX100 での新命令セット HPC-ACE2 に対して本ベンチマークコードを移植するにあたって最大の問題だったのは、当時のコンパイラでは SIMD 組込み関数
が未サポートであったことである。このことはマニュアルにも明示的に書かれていたが、「一切サポートしない」というよりはもう暫くの間待つようにという話のようであった。
開発陣が気を利かせてくれたのかどうかは定かではないが、処理系のインクルードパスを見てみるとそれらしいヘッダファイルは存在したので、これを使ってみることにした。
未サポートの機能を勝手に使おうというのだからこれは完全に自己責任（とはいえシス
テムを破壊するようなものではない）なのだが、少し間違えるとコンパイラのプロセスを落としてしまったり（コアダンプが出るだけでシステム障害は引き起こさない）といった試行錯誤があった。注意が必要だったのは、HPC-ACE 互換の動作をする SIMD2 モード、HPC-ACE2 で拡張された動作をする SIMD4 モードの間は切り替え命令で行き来するという点である。インテルアーキテクチャでは命令長をどんどん延ばすかたちで命令フ
ィールドの拡張が可能であるが、固定長命令の SPARC ではそのようなことはできないのでこのような仕組みになっている。当時のコンパイラではこのモード切替をソースコードの文脈から認識して行うという部分に問題があったようで、逆にこの部分を手動で行うことで（未サポートの）SIMD 組込み関数は十分に実用的であった。性能であるが、同じ 16 コアで比べた時に FX100 が Xeon より若干良い数字になっている。Xeon は定格
で 2.3 GHz、AVX 使用時の TurboBoost が 2.5 GHz であり、FX100 は 1.975 GHz で演算器の数は 256-bit dual FMA と共通している。やはりレジスタの本数が 128 本と多いことが効率向上に寄与しているものと思われる。ただし粒子数の少ない領域では若干見劣りする結果となっており、同期やコア間通信が高速なアーキテクチャなだけにこの部分をもう少し頑張って欲しいと思う。Xeon-Phi であるが、粒子数が十分に大きな領域で Xeonの 1.5 倍程度の性能となっている。Xeon に AVX-512 が実装されてしまうと、演算器の数、レジスタ幅、レジスタの本数が全て２倍となるため、この商品の系列がどうなってしまうのか不安になる。

180 / 253

N体計算ベンチマーク
2015/3/17 SS研P‐PAP WG
理研AICS 似鳥啓吾

話の予定
1. 計算コードの概要
2. HPC‐ACE向けの実装
3. 性能

181 / 253

コードの概要• ブロック時間刻みHermite積分法のN体計算ベンチマーク（詳細は後述）– 球状星団や惑星系形成で広く使われているスキーム• 複数アーキテクチャに向けて手動SIMD化– これまでにAVX, HPC‐ACE, Xeon‐Phi, CUDAのバージョン– フル倍精度演算をベンチマークのルールとした– 現状シングルノードのみ対応• 4, 6, 8次精度の積分法を実装– 重力の高階導関数を解析的に計算– アーキテクチャごとに3種類のカーネルチューンが発生• 言語は「一応」C++03– 移植性、可読性、可搬性は考慮されていない– ソースは github.com/nitadori/Hermite/SRC/

N体計算の支配方程式• 本当にこれを積分するだけ– 細かな話は無数にあるわけですが• 減算３回、積和６回、乗算３回、逆数平方根１回• i‐loopとj‐loopの二重ループ、O(N2)• j‐粒子がi‐粒子を引っ張る• i‐並列とj‐並列のふたつの並列度– i‐並列ではj‐粒子の放送によってメモリ帯域を節約– j‐並列では最後に部分力の総和演算が必要
182 / 253

ループボディ••

流用資料につき混合精度
外側ループのomp parallel
化は自明に近い•レジスタが余っていたら外側ループをアンロール
j‐粒子がキャッシュに収まるようなブロック化／並列化も有効•

Hermite積分法
f
i

i+1

v
t

• 加速度の時間微分を直接計算• ２点間のでの補間多項式から４次精度を得る• 予測子修正子法のひとつ• もっと高階の微分を用いて６次、８次精度も可能
183 / 253

力の高階微分• 式を整理すると項数は線形にしか増えない– 次数の二乗のコスト• 積和算の比率が増える• レジスタ消費も増える• 平方根は一回だけ

独立時間刻み法 (Aarseth 1963)• 粒子ごとの時間刻みΔtiを持つことを許す– 他の粒子の座標に「予測子」を用いることで実現– 最近では並列度を稼ぐために刻みを二冪に丸める• 同時に積分できる粒子数はそんなに多くない– Nact∝N2/3 程度でGPUのスレッド数より少ない– 一回の計算量がO(NactN)
1/1

1/2

1/4

1/8

184 / 253

1ステップの手続き
1.
2.
3.
4.
5.

積分する粒子を選ぶ：O(Nact) or O(logN) (serial)
全粒子の予測子を計算：O(N) (parallel)
重力を計算：O(NactN) (parallel)
修正子と新しい刻み幅を計算：O(Nact) (parallel)
粒子を時間刻でソート：O(NactlogNact) (serial)• GPUでは2と3をオフロード、ホストとの通信はO(Nact)• Nact∝N2/3, 系にもよるが係数も１ぐらい– 細かな同期の入るコードになる– ステップあたりO(N1.66)の相互作用計算、単位時間の積分にO(N0.66)ステップ、トータルO(N2.33)

HPC‐ACE向けのチューニング
• コンパイラベースのSIMD化には制限が多い– 粒子法全般、他社製品も同様– 分岐の排除が職人芸的だったり、外側ループの並列度が有効だったりするため• 幸い、Kernelだけ組込み関数で書くのはそれ程大変ではない– 比較的単純なホットスポットが明確なため• 方針– 組込み関数クラスラッパでできるだけスッキリと書く– 明示的なSIMD化と同時に、ロード命令を極力減らす（レジスタレベルの再利用）

185 / 253

SIMD組込み型／関数• C/C++言語使用手引書の巻末に一覧がある– v2r8型 (vector 2 real‐kind 8)、v2r4型、v2i8型– __builtin_fj_xxx()のような組込関数多数– 倍精度演算はSSE2/3と同じような使い勝手

積和命令• 符号も入れて6‐bit分のフィールド、64個の組込み関数– madd : D := A×B + C– msub : D := A×B − C– nmadd : D := −(A×B + C)
– nmsub : D := −(A×B − C)
– _sr1 : Aの上下語swap– _sr2 : Bの上下語swap– _cp : Aの下位語放送（sr1と合わせて上位語放送）– _neg : A×Bの上位語符号反転– 最長でnmsub_cp_neg_sr12_v2r8()• DGEMMや複素数のことを考えた設計• オペランド放送は粒子法にも有用

186 / 253

クラスラッパ
static inline v2r8 gp3m_force(
const v2r8 r2, const v2r8 r, const v2r8 rinv){
const v2r8 mask = v2r8_cmplt(r2, immr8(4.0));
const v2r8 s= v2r8_sub(v2r8_max(r, immr8(1.0)), immr8(1.0));
const v2r8 s2 = v2r8_mul(s, s);const v2r8 s6 = v2r8_mul(s2, v2r8_mul(s2, s2));
const v2r8 poly1 =v2r8_madd(
v2r8_msub(
v2r8_madd(
v2r8_msub(
v2r8_msub(
immr8(3./20.),r,
immr8(12./35.)),r,
immr8(1./2.)),r,
immr8(8./5.)),r2,
immr8(8./5.)),r2,rinv);
const v2r8 poly2 =v2r8_nmsub(
v2r8_madd(
immr8(3./35.),
rinv,
v2r8_madd(
immr8(1./5.),r,
immr8(18./35.))),
s6,
poly1);
return v2r8_and(poly2, mask);}• 流石にこんなものを生で書き続けるのはしんどい• 多項式ぐらいは演算子で書きたい• C++ならクラスに演算子定義できる– まともにレジスタに載るコードが生成できたのは２年前ぐ
らい←2012年春のコード

クラスラッパ（続き）
組み込み型をラップする

演算子は普通に定義

struct v2r8{
typedef __builtin_v2r8 _v2r8;_v2r8 val;

v2r8 operator+(const v2r8 rhs) const {return v2r8(__builtin_fj_add_v2r8(val, rhs.val));}v2r8 operator‐(const v2r8 rhs) const {return v2r8(__builtin_fj_sub_v2r8(val, rhs.val));}v2r8 operator*(const v2r8 rhs) const {return v2r8(__builtin_fj_mul_v2r8(val, rhs.val));}v2r8(const v2r8 &rhs) : val(rhs.val) {}v2r8 operator=(const v2r8 rhs){
val = rhs.val;
return (*this);}// コピーコンストラクタと代入演算子は忘れないこと
v2r8() : val(__builtin_fj_setzero_v2r8()) {}v2r8(const double x): val(__builtin_fj_set_v2r8(x, x)) {}v2r8(const double lo, const double hi): val(__builtin_fj_set_v2r8(lo, hi)) {}v2r8(const _v2r8 _val) : val(_val) {}operator _v2r8() { return val; }•積和化はコンパイラがやってくれる•

参照渡しより値渡しの方が上手くレジスタに載ってくれることが多い};

187 / 253

自動アンロール型、放送型• レジスタを２本消費しレイテ
ンシを隠蔽• AVXやHPC‐ACE2と互換
struct v4r8{
typedef __builtin_v2r8 _v2r8;_v2r8 v0, v1;• 上下語を放送して演算• 積和命令を騙して使う
struct v2r8_bcl{
typedef __builtin_v2r8 _v2r8;_v2r8 val;
v2r8 operator‐(const v2r8 rhs) const {const v2r8 one(1.0);
return v2r8(__builtin_fj_msub_cp_v2r8(val, one.val, rhs.val));}v2r8 operator*(const v2r8 rhs) const {const v2r8 zero(0.0);
return v2r8(__builtin_fj_madd_cp_v2r8(val, rhs.val, zero.val));}v4r8(const v4r8 &rhs): v0(rhs.v0), v1(rhs.v1) {}v4r8 operator=(const v4r8 rhs){
v0 = rhs.v0;
v1 = rhs.v1;
return (*this);
}
};

};

粒子法での応用• ２粒子×２粒子で４相互作用並列
const v2r8 xi, xj;
const v4r8 dx = v4r8_llhh(xj) ‐ v4r8(xi);• 実際には、
msub_cp_v2r8(lhs, 1.0, rhs);
msub_cp_sr1_v2r8(lhs, 1.0, rhs);

が呼ばれる• 過度の抽象化は可読性を妨げるという典型
例

188 / 253

#pragma omp for // calculate partial force
for(int j=0; j<nj; j+=2){
const v2r8 mj = pred[j/2].mass;const v2r8 xj = pred[j/2].pos[0];const v2r8 yj = pred[j/2].pos[1];const v2r8 zj = pred[j/2].pos[2];const v2r8 vxj = pred[j/2].vel[0];const v2r8 vyj = pred[j/2].vel[1];const v2r8 vzj = pred[j/2].vel[2];最内ループ• 見た目だけは単純• コンパイラはここから更にアンロールとソフトウェア
パイプライニングする

const v4r8 dx = v4r8_llhh(xj) ‐ v4r8(xi);const v4r8 dy = v4r8_llhh(yj) ‐ v4r8(yi);const v4r8 dz = v4r8_llhh(zj) ‐ v4r8(zi);const v4r8 dvx = v4r8_llhh(vxj) ‐ v4r8(vxi);
const v4r8 dvy = v4r8_llhh(vyj) ‐ v4r8(vyi);
const v4r8 dvz = v4r8_llhh(vzj) ‐ v4r8(vzi);• プロファイラは対ピーク75%を報告const v4r8 r2 = ((v4r8(eps2) +dx*dx) + dy*dy) + dz*dz;
const v4r8 rv = (dx *dvx + dy *dvy) + dz *dvz;
const v4r8 rinv
= r2.rsqrta_x8();
const v4r8 rinv2 = rinv * rinv;
const v4r8 mrinv = rinv * v4r8_llhh(mj);const v4r8 mrinv3 = mrinv * rinv2;• 減算が積和命令で水増しされたため• 若干の$L1D待ちないし演算待ちが残るconst v4r8 alpha = v4r8(‐3.0) * rv * rinv2;
ax += mrinv3 * dx;
ay += mrinv3 * dy;
az += mrinv3 * dz;
jx += mrinv3 * (dvx + alpha * dx);
jy += mrinv3 * (dvy + alpha * dy);jz += mrinv3 * (dvz + alpha * dz);
} // for (j)

逆数平方根
•
•
•

8‐bit精度の近似命令がある
任意の次数の収束公式を構築可能
いくつか試したけどコンパイラの出すのと同じ二次収束を３回に落ち着いた

v2r8 rsqrta_x8() const {const v2r8 x(val);const v2r8 y0 =v2r8(__builtin_fj_rsqrta_v2r8(val));const v2r8 half(0.5);
const v2r8 xhalf = x * half;const v2r8 h0half = half ‐ y0*(y0*xhalf);
const v2r8 y1 = y0 + y0*h0half;// x2
const v2r8 h1half = half ‐ y1*(y1*xhalf);
const v2r8 y2 = y1 + y1*h1half;// x4
const v2r8 h2half = half ‐ y2*(y2*xhalf);
const v2r8 y3 = y2 + y2*h2half;// x8
return y3; // 4‐mul, 6‐fma}••

SSE/AVXだと12‐bit相当
こちらは五次収束一発を採用#define REP4(x) {x, x, x, x}
static inline v4df v4df_rsqrt(const v4df x){
const v4df y0 =__builtin_ia32_cvtps2pd256(__builtin_ia32_rsqrtps(__builtin_ia32_cvtpd2ps256(x)));const v4df c0 = REP4(1.0);
const v4df c1 = REP4(0.5);
const v4df c2 = REP4(3./8.);
const v4df c3 = REP4(5./16.);
const v4df c4 = REP4(35./128.);
const v4df h = c0 ‐ x*y0*y0;
const v4df y1 = y0 * (c0 + h * (c1 +h * (c2 + h * (c3 + h * (c4)))));
return y1;}

189 / 253

Kernel profile (thanks Dr. Maruyama)• 上から順に４次、６次、８次のカーネル

Haswell i7 4C8T 3.40 GHz,
積分も含めた実行性能 • Intel
16 flops/cycle, 207.6 Gflops• Fujitsu FX10 16C16T 1.848 GHz,
8 flop/cycle, 236.5 Gflops

190 / 253

性能の解釈• Dual FMAのCPUで一応ピークの半分程度– 対ピークではFX10の方がいい、これはレジスタが16
本か128本かが効いていそう• 低粒子数でのFX10の起ち上がりが若干悪い– 最内ループをスレッド並列にしたので短くなりすぎた– もう少し真面目に割り当てれば改善するかも（同期は速いはず）– 高次積分法の方が起ち上がりがよく、並列計算機に向いている

おまけ（MICとGPU）

191 / 253

• Intel KNC 5110p 60C240T 1.053 GHz,
16 flop/cycle, 1011 Gflops• GeForce Titan 14SMX, 64 FMA/SMX,
1300 Gflops

拡大図• ホストとの通信の無いMICが低粒子数で豪快に遅い• OpenMPの同期がCUDAのAPIコールより数倍遅いため

今後• Xeon E5 v3 (12C, 16C)を調達したので測ってみたい– AVX‐512は当面先になりそう• 和光のHOKUSAIの試験利用申請に名前を入れてもらった– マニュアルとコンパイラにアクセスできるようになる見
通し• MPI並列版も要望がきたのでやってみる– HPLのようにコミュニケータを2次元分割– 集合通信のレイテンシに敏感なコードになる

192 / 253

N体計算ベンチマーク（FX100 Hokusaiを使ってみた）
2015/7/1 SS件P-PAP WG
理研AICS 似鳥啓吾

コードの概要と宿題• 色々なSIMDアーキテクチャ向けにN体計算
ベンチマークコードを書いている– AVX, HPC-ACE, MIC KNC, AVX2, CUDA
– C++とSIMD組込み関数、OpenMPを使用• 宿題– 理研和光のFX100アカウントが発生したので何か試す– 16コアのHaswell Xeonを調達したのでベンチマーク
2
193 / 253

前回からのアップデート• OpenMPの同期オーバーヘッドを軽減した– Core i7 4C/8TからXeon 16C/32Tに行くとparallel
スコープの開閉コストが馬鹿にならなくなってきたため– parallelスコープは開きっぱなしにして中でbarrierを入れながら並列化した• AICS研究部門保有のFX10は1.83GHzではなく1.65GHzだった– ピーク性能の計算間違い、結果対ピークは改善• FX100のHPC-ACE2版のコードを追加
3

HPC-ACE2版の障壁

4
194 / 253

「SIMD組込み関数は未サポート」• 丁寧にヘッダでコンパイルエラーにしている<emmintrin.h># if defined(__HPC_ACE2__)#
error "HPC‐ACE2 instruction set not enabled"# endif /* defined(__HPC_ACE2__) */• ただしバイナリ互換はあるので京やFX10でコンパイルしたものを持ってくるという手はある

5

別のヘッダを漁ってみる$ ls /opt/FJSVmxlang/GM‐2.0.0‐02/include/blas_enum.hfjcoll.hblas_extended_proto.h fjcoll_lib.hc++fjcoll_lib.modc++521fjhook.hc++fastfjintrin.hcomplex.hfjmfunc.h
cssl.hfloat.hemmintrin.h
ieee_arithmetic.mod
fast_dd.h
ieee_exceptions.mod
fast_dd.mod
ieee_features.mod
fast_dd_inline.h
iso646.hfeatures.h
iso_c_binding.mod
fj_lapack.h
iso_fortran_env.mod
fj_tool
lapacke.h
fjcex.hlimits.hmath.hmpi
mxintrin.h
omp.h
omp_lib.h
omp_lib.mod
omp_lib_kinds.mod
service_routines.mod
setjmp.hstdarg.hstdbool.h
stddef.htgmath.hvampirtrace
varargs.h
6

195 / 253

mxintrin.h• HPC-ACE2の命令が網羅されているっぽい• ぱっと見「使えそう」、現状では制限も多い– SIMD長が4か2かのモード切り替えはユーザーの責任で– 一部の関数は呼ぶだけでコンパイラがsegmentation
fault– 一部の関数は呼び方によってはコンパイラがsegmentation fault– 最適化レベルの指定が低いとコンパイラがsegmentation fault• 未サポートの機能を勝手に使おうという方が悪い

7

SIMD mode 2/4• モード切り替え命令でSIMD2/SIMD4を切り替える– SIMD2: K/FX10互換の動作 (SSE相当)– SIMD4: FX100での拡張 (AVX相当)– 命令フィールドに空きがなかった？
• 切り替えコストはnop程度の模様• sxar同様命令フィールドを補う命令らしい– 切り替え方を間違えるとillegal instructionで落ちたり結果が半分だけになったり• 基本コンパイラが発行してくれる命令です8
196 / 253

OpenMPとの組み合わせ• 若干コンパイラの挙動に問題が残っているよ
うなので要注意– くどいけど悪いのは未サポートの機能を勝手に使っている側です#pragma omp parallel{_fjsp_simd_mode_4(); // optimized out of the scopeasm volatile (“ssm 1”); // WTF, it runs!!
v4r8...
}
9

Element Concatenate Shift Left
• 要素を２つ連結して左にシフト– 64-bit単位で即値シフトできるので色々なシャッフルに応用可能ecsl a, b, 1

a0

a1

a2

a3

b0

b1

b2

b3

ecsl a, b, 2
ecsl a, b, 3

10
197 / 253

応用: 4×4行列転置• 一度作っておくと重宝する• メモリ経由でstride loadでも可能
static void transpose(v4r8 &a, v4r8 &b, v4r8 &c, v4r8 &d){// 6‐fsel, 8‐ecsl, 2‐mask‐reg
const v4_mask m1010(1,0,1,0);
const v4_mask m1100(1,1,0,0);v4r8 a0b0a2b2 = m1010.select(a,b.ecsl(b,3));//a0a1a2a3
b3b0b1b2
v4r8 a1b1a3b3 = m1010.select(a.ecsl(a,1), b);//
a1a2a3a0
b0b1b2b3
v4r8 c2d2c0d0 = m1010.select(c.ecsl(c,2), d.ecsl(d,1));//
c2c3c0c1
d1d2d3d0
v4r8 c3d3c1d1 = m1010.select(c.ecsl(c,3), d.ecsl(d,2));//c3c0c1c2
d2d3d0d1
v4r8 a0b0c0d0 = m1100.select(a0b0a2b2, c2d2c0d0);
v4r8 a1b1c1d1 = m1100.select(a1b1a3b3, c3d3c1d1);
v4r8 a2b2c2d2 = a0b0a2b2.ecsl(c2d2c0d0, 2);
v4r8 a3b3c3d3 = a1b1a3b3.ecsl(c3d3c1d1, 2);a = a0b0c0d0; b = a1b1c1d1; c = a2b2c2d2; d = a3b3c3d3;
}

11

実装方針
• 組込み型、組込み関数はとりあえずC++のクラスでラップ– この部分はコンパイラが期待通りにインライン展開してくれた• 粒子間相互作用のSIMD化には放送ロード命令を多用した– レジスタ内でのシャッフルは控えた（積和とポート競合しそうだったから）– 自動アンロール型のような複雑な機能は今回は控えた（とりあえず動かすことを優先）
12
198 / 253

OpenMPチューニング
• 前回まで：いくつかのループに#pragma
omp parallel forをつけていた– 簡単だが開始／終了オーバーヘッドが大きい• 今回のチューン：パラレルスコープは長期間開いておき、omp for nowaitやomp
barrierで書く– コードの書き直し量が多い– 少し同期を間違えるとデータ化け13

性能評価• Xeon E5-2698 v3: 16C32T,
640Gflops@2.5GHz (AVX turbo)• Xeon Phi 5110P: 60C240T, 1.053GHz,
1011Gflops• FX10: 16C, 1.65GHz, 211Gflops• FX100: 32C, 1.975GHz, 1011Gflops– 16スレッドと32スレッドで測定

14
199 / 253

Performance (Xeon)
Gflops Xeon 16C/32T (peak 640)
350
300
250
200
150
100
50
0
1000

4th
6th
8th
10000

100000N
15

Performance (Xeon Phi)
Gflops KNC 60C/240T (peak 1010)
500
450
400
350
300
250
200
150
100
4th
6th
8th

50
0
1000

10000

100000N
16200 / 253

μsec/block-stepsec/block Xeon vx. MIC
100000

10000

1000

MIC 4th
MIC 6th
MIC 8thXeon 4th
Xeon 6th
Xeon 8th
 x5/3

100

10
1000

10000

100000N
17

FX10 (1.65GHz)
Gflops FX10 16C (peak 211)
160
140
120
100
80
60
40
4th
6th
8th

20
0
1000

10000

100000N
18
201 / 253

FX100 (16T/32T)
Gflops FX100 16T vs. 32T (peak 505 vs. 1011)
700
600
500
400
300
200

16T 4th
16T 6th
16T 8th
32T 4th
32T 6th
32T 8th

100
0
1000

10000

100000N
19FX100 vs. Xeon
Gflops FX100 16T vs. Xeon (peak 505 vs. 640)
350
300
250
200
150
100

FX100 4th
FX100 6th
FX100 8th
Xeon 4th
Xeon 6th
Xeon 8th

50
0
1000

10000

100000N
20
202 / 253

まとめ
• 同じ256-bit dual FMA 16 coreの条件でFX100がHaswellより少し速かった– レジスタが128本と豊富にあるのが効いているのだと思う– PAを見るとまだ演算待ちが残っている• 粒子数の少ない所での性能起ち上がりではXeonより若干悪くなってしまった– 同期そのものは圧倒的に速いはず– ループ回転数が小さくなった為かも（外側ループアン
ロール等のチューニングの余地あり）
21

203 / 253

2.11 NGS データ処理プログラム BWA の評価について
理化学研究所 情報基盤センター
野田 茂穂、須永 泰弘
2.11.1 概要：ゲノムデータを取得する NGS（NextGeneration Sequencer）では、計測結果として得られる断片的なゲノム配列を処理することにより全長配列データを得ることができる。この処理は二次解析と呼ばれており、Assemble 処理やMapping 処理が該当する。現在、NGS が大量に導入されゲノムデータの取得が頻繁に行われており、二次解析を処理する計算機も大量に必要になってきている。
2.11.2 処理及びプログラム概要：この評価では、二次解析のうち Mapping 処理に着目している。
Mapping 処理ではあらかじめ用意されているリファレンスゲノム配列を利用し、取得した断片ゲノ
ム配列から全長配列を得ることができる。断片ゲ
ノム配列の総量は求める精度により変わるがおお
よそ 30Gbp（bp : base pare 塩基対 A,T,G,C）であり、リファレンス配列は 3Gbp、出力される全長
配列も 3Gbp である。
マッピングのツールとして幾つかのソフトウェア
がリリースされているが、京コンピュータ向けに作成された NGSAnalizer が使用している BWA を対象に FX100 での動作検証及び性能評価を行った。
bwa の実行は、”bwa aln ref.fa read.fast > res1.sai”という実行する。ref.fa がリファレン
スゲノム配列であり 3.1GB のアスキーファイル。read.fast が断片ゲノム配列で 13.5GB、出力である rea1.sai が 23GB のバイナリーデータである。
プログラムは C 言語で 10K ほどのものであり、キーとなるアルゴリズムは Burrows Wheeler
Transform を使用している。
2.11.3 評価結果概要：FX10 と FX100 で単体性能（core あたり性能）はほとんど変わらない。これは SIMD 命令などの高速化の恩恵を得ることができないプログラムのためである。しかしながら、スレッド並列は良好であり、メニーコアの恩恵が得られるプログラムであることがわかる。

204 / 253

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

NGSデータ処理プログラムBWA
独立行政法人 理化学研究所
情報基盤センター
野田 茂穂

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

NGSデータ処理の流れ
NGS: Next Generation Sequencer
ヒトゲノムデータ：3Gbp ( bp : base pair塩基対A,T,G,C)
NGS装置は断片化されたゲノム配列を出力。一つのデータは100bp程度。
断片化されたゲノム配列を参照ゲノム配列を利用し一本のゲノム配列を作成。

205 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

次世代シークエンサー(ハイスループット型)

参考：
第１世代自動シークエンサー
3130xl (ABI)

Hiseq2500（イルミナ）

GSFLX+（ロシュ）

600Gb/11日

0.7Gb/23時間
リード長：700bp

リード長：2×100bp

5500xlw（ライフテクイノロジーズ）
270Gb/14日
リード長：2×60bp
bp : base pair[塩基対]次世代シークエンス解析ソフト講習会
All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

HiSeq XTM Ten（2014年4月販売開始）

NGSも並列化の時代へ！
10台のHiSeq XTM を同時に動かす

HiSeq Xシステムは、1台のシステムで最大1.8テラベース（Tb）のデータを3 日以内に産出(600Gb/day)
10台のシステムで最大320テラベース（Tb）のデータを毎週産出
引用元：イルミナ社HiseqXten データシート
206 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

断片ゲノム配列データ
ACGTACGT…..ACGTACGT : 約3Gbp[ACGT……ACGT] : 400bp[ACGT……ACGT] : 400bp[ACGT……ACGT] : 400bp[ACGT……ACGT] : 400bp

NGS

7,5000,000リード
Fastqファイル[ACGT……ACGT] : 400bp[ACGT……ACGT] : 400bp[ACGT……ACGT] : 400bp[ACGT……ACGT] : 400bp
All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

断片ゲノム配列データのアライメント
断片ゲノム配列データが参照ゲノムデータのどこに当てはまるかを探索。
正、全く同じゲノム配列ではないため、近い所を探す。
また、精度を高めるため、カバレッジを１０程度とる。
断片ゲノム配列データの総量は3Gbp×10=30Gbp。

……………….

………………. ………………. ……………….

[ACGT……ACGT][ACGT……ACGT][ACGT……ACGT][ACGT……ACGT]……………….

……………….

ACGTACGTACGTACGTACGTACGTACGTACGT….. ACGTACGTACGTACGTACGTACGTACGTACGT

参照ゲノムデータ：既に分かってるゲノム配列
207 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

NGSのフローチャート
ゲノムDNAここ
は装NGSを使って塩基配列解読
生データ（画像データ等）

置

一次解析：Base caller
生データを配列データに変換
大量の断片
配列データ

2次解析:
Assemble & Mapping

３次解析

全長
配列データ

アノテーション付配列データ

変異(SNP）同定
転写物解析

ここが対象

サテライトマーカー同定

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

マッピングツール(ショートリード・ゲノム用)
名前

アルゴリズム

BWT(Burrows-Wheeler
Transform)

BWT

BWT

挿入欠失(In/Del)

検出可能

検出可能

検出不可能

処理速度

速い

とても速い

速い
メモリ消費量少ない

精度

良い

BWAより悪い

BWAより悪いpthreadSSE

GPL v3academic free binary

スレッド並列化ライセンスpthread(ｖ0.5，v0.6)
SSE2(v0.7)
GPL v3

今回はFX10と「京」で動作確認がとれている、BWAの詳細プロファイルを取得した。
208 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

NGSデータ処理の流れ(bwa)
ヒトゲノムデータ：3Gbp(G base pair塩基対A,T,G,C)
NGS装置は断片配列ゲノムデータの塩基配列を出力。一つのデータは100bp程
度。
ソフトウェアでMapping処理を行い、細切れデータを一つのヒトゲノムデータに整形。Mapping処理とは元となる参照ヒトゲノムデータに細切れデータを当てはめて行き、参照ヒトゲノムデータに近いゲノムデータを生成する。
処理はアライメントとマッピングに分けて実行される。
精度の確保の為、一つのゲノムに対して１０回程度計測を行いそのNGSデー
タを使用する。(10カバレッジ)
入力：参照ヒトゲノムデータ3Gbp、NGSデータ30Gbp
実効例：
bwa aln ref.fa read_1.fastq > 1.saibwa aln ref.fa read_2.fastq > 2.saibwa sampe ref.fa 1.sai 2.sai read_1.fastq read_2.fastq > result.sam
All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

プログラム概説• C言語、約10K。
• bwa aln : 断片ゲノム配列データを参照ゲノム配列にアライメント• bwa sampe : アライメントされたデータから一つのゲノム配列を生成（マッピング）• アルゴリズム概要(bwa aln)
Loop:断片ゲノム配列データ数(7,500,000×10)
bwtアルゴリズムを用いて探索
endloop• FX10上でマッピング処理を行う以下のファイルサイズで動作• 実効例：
bwa aln ref.fa read_1.fastq > 1.saibwa aln ref.fa read_2.fastq > 2.saibwa sampe ref.fa 1.sai 2.sai read_1.fastq read_2.fastq > result.sam （正、時間内に終了せず）• ref.fa[参照配列データ]:3.1GB(ASC), read_1.fastq[NGSのデータ]:13.5GB, read_2.fastq[NGSのデー
タ]:11.8GB, 1.sai[bwa alnの結果]:2.6GB(Bin) 2.sai[bwa alnの結果]:3.3GB(Bin), result.sam[配列データ＋スコアデータ]:3.9GB(Bin)• Bwa alnはスレッド並列、bwa sampeは非並列

209 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

Burrows Wheeler Transform(BWT)
BWA, Bowtieが使用しているアルゴリズム
ブロックソートとも呼ばれる。Bzip2など
リファレンスゲノムの配列を断片化し、インデックスを作成する。
① Suffix Arrayの作成(1)
配列A CAGGTT(1) 末尾に目印として$をつける。

CAGGTT$(2) 先頭の文字を末尾に移動する。

AGGTT$C(3) 先頭の文字を末尾に移動する。

GGTT$CA(4) 先頭の文字を末尾に移動する。

GTT$CAG(5) 先頭の文字を末尾に移動する。

TT$CAGG(6) 先頭の文字を末尾に移動する。

T$CAGGT(7) 先頭の文字を末尾に移動する。

$CAGGTTAll Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

Burrows Wheeler Transform(BWT)② Suffix Arrayの作成(2)配列A CAGGTT
番号をつける
1

CAGGTT$

2

AGGTT$C3

アルファベット順に並べ替える（辞書順にソート）

7$CAGGTT

2

AGGTT$C

GGTT$CA1

CAGGTT$

4

GTT$CAG3

GGTT$CA

5

TT$CAGG

4

GTT$CAG6

T$CAGGT

6

T$CAGGT

7$CAGGTT

5

TT$CAGG

これがSuffix Array
A[0] = 7, A[1] = 2
210 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

Burrows Wheeler Transform(BWT)③ 文字列検索

配列A CAGGTT

7$CAGGTT

2

AGGTT$C

7$1

CAGGTT$

2

A GGTT$

3

GGTT$CA1

C AGGTT$

4

GTT$CAG

3G GTT$

6

T$CAGGT

4

G TT$

5

TT$CAGG

6

T $

5

T T$

＄以下を切り捨てる

1列目から順々に文字検索するだけで、その文字の位置
Suffix Arrayも決定できる

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

BWAのマッピング
デフォルトの場合

NGSで読んだ配列

100〜200塩基

Seed length
32塩基①5’側（上流）からSeed length(32塩基)までの塩基配列をBWTを用いてゲノム上の領域を探索する。(2塩基以下のミスマッチ、ギャップを許容)②Seedがマッチした配列の残りの部分をアライメントし、最大許容ミスマッ
チ以下のアライメントを求める。
③ゲノム上の複数箇所にアライメントされるが、最もスコアの高い位置にマッピングする。

④同一スコアで複数の場合はランダムに1カ所を選ぶ

211 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

今回の計算に使用したデータ
１．参照（リファレンス）ゲノムデータ☆NCBIのBuild37.1（標準ヒトゲノム）①全ゲノム(1〜22, X, Y) （アライメント用）
2.8 GB (29億塩基対)②第1番染色体（一番長い）のみ (マッピング用)
220 MB (2億2千6百万塩基対)全ゲノムでのマッピング測定は時間切れで計測できず

2．NGSデータ
Illumina社のGAから出てきたfastqファイル
13GBと12GB (ペアーエンド)

ftp://ftp.ddbj.nig.ac.jp/ddbj_database/dra/fastq/DRA000/DRA000222/
All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication

bwa-0.6.2の計算の流れ

FX-10でプロファイルを取得した。
１． ゲノムインデックスの作成(逐次計算)
２． アライメント処理(pthread)
16 threads で計算
３． マッピング処理(逐次計算)

212 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication
アライメント処理(ala)詳細プロファイルの実行時間

FX-10でプロファイルを取得した。(16 threads)
ELAPSE TIME (USE)CPU TIME (TOTAL)

PA1

01:04:48 (3888)

50746660 ms

PA2

01:05:03 (3903)

50745960 ms

PA3

01:04:31 (3871)

50656650 ms

PA4

01:04:49 (3889)

50726070 ms

PA5

01:14:13 (4453)

51262090 ms

PA6

01:04:39 (3879)

50635080 ms

PA7

01:11:15 (4275)

51204460 ms

実行時間にばらつきが生じる。
All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and CommunicationhņĬěĦĹč ~

()

ľĿ

()

$%LMBFGJ58=< 2%#%%"%

LMBFGJ58=< 2

<A5 2
LMB7H@:I58=< 2

%



!%%LMB7H@:I58=< 2 2%

 2

%%  2%

D6@? 2%CJ5 2%%/&'9E@A%

133 2%'-,*+..%







9E@A%













K;<>04%9E@A%

%'-,*+..















9E@A











ÊË%

213 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and CommunicationhņĬěĦĹč ~
メモリ・キャッシュエンジン ビジー率     







 

 

 

    

 

 

 

 





SIMD命令率  





  

    





  







    







  ÊÌ

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and CommunicationhņĬěĦĹč ~
キャッシュミス率（/ロード・ストア数）
 

































 L1Dキャッシュミス内訳（/L1Dキャッシュミス数）
 







  





 





 

L２キャッシュミス内訳（/Ｌ２キャッシュミス数）








 









  

ÊÍ

214 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and CommunicationhņĬěĦĹč ~
実行時間内訳 [概略] （/実行時間)
'#$'#$

&#"  )!     

'#$%(  

 

 

 

 

 
 

   

     

   

 

 



 

命令内訳 (/有効総命令数)
   
 















 



  









  ÊÎ

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communication
マッピング処理(sampe)
詳細プロファイルの実行時間

FX-10でプロファイルを取得した。(1 thread)
ELAPSE TIME (USE)CPU TIME (TOTAL)

PA1

02:49:54 (10194)

10080340 ms

PA2

02:51:48 (10308)

10191260 ms

PA3

02:51:05 (10265)

10159770 ms

PA4

02:51:32 (10292)

10176190 ms

PA5

02:50:48 (10248)

10132920 ms

PA6

02:51:30 (10290)

10184520 ms

PA7

02:51:38 (10298)

10196100 ms

実行時間にばらつきはない。
215 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communicationh  ņĬěĦĹč ~

()

ľĿ

()

%

%

LMBFGJ58=< 2$%

LMBFGJ58=< 2

<A5 2

%

#%

LMB7H@:I58=< 2%

LMB7H@:I58=< 2"% 2

%

!%

 2

%  2
%%

%

D6@? 2
CJ5 2%

/&'9E@A

%

133 2%

%

9E@A%

K;<>04

%

9E@A%

%
'-,*+..









'-,*+..









9E@A











%














ÊÐ 



All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communicationh  ņĬěĦĹč ~
メモリ・キャッシュエンジン ビジー率     







 

 

 

 

    

 

 

 





SIMD命令率  





  





    





  





    







  

ÊÑ

216 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communicationh  ņĬěĦĹč ~
キャッシュミス率（/ロード・ストア数）
 






































 L1Dキャッシュミス内訳（/L1Dキャッシュミス数）
 







  





 





 

L２キャッシュミス内訳（/Ｌ２キャッシュミス数）








 









  ËÈ

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

Yokohama,, ACCC,, RIKEN
Advanced Center for Computing and Communicationh  ņĬěĦĹč ~
実行時間内訳 [概略] （/実行時間)
'#$'#$

&#"  

)!    

 

 

 

'#$%(  

 

 



 

 

 



 

命令内訳 (/有効総命令数)
   
 






 
 

   

     

  










 








  







  

ËÉ

217 / 253

All Rights Reserved, Copyright © Yokohama, ACCC, RIKEN  2013

SS研 ポストペタアプリ性能WG資料

BWAのFX10性能報告

2014年12月10日
富士通株式会社
ＴＣソリューション事業本部
Copyright 2014 FUJITSU LIMITED

目次
 目的・アプリ概要
 動作環境・実行結果
 プロファイラ結果
 関数呼び出し･ループ構造
 精密ＰＡ情報
 ソースコード分析
 まとめ

1

218 / 253

Copyright 2014 FUJITSU LIMITED目的・アプリ概要
 目的
 FX10実行でホットスポットの特定• ホットスポット特定はfipp ホットスポットの演算パターン、メモリアクセスパターン分析• 分析方法は、1．精密PA 2．ソースコード分析

 アプリ概要
 アプリ名：bwa (Burrows-Wheeler Alignment Tool)

 処理概要： ゲノムマッピングを行うツール。複数回プログラム実行が必要。
インデックスファイル作成

アライメント実行1
アライメント実行2

マッピング実行 バージョン： 0.5.10
 並列化手法: pthredによる並列化。ＭＰＩ並列は無し。
 記述言語:C

 コード行数: 8940
 入力(NGS)データ： 日本人の公開ゲノムデータ
2

Copyright 2014 FUJITSU LIMITED

動作環境・全体実行時間
 動作環境
システム

FX10

CPU

SPARC64IXfx

周波数1.85GHz

コンパイラ

fccpx
P-id: T01641-04

オプション-Kfast -Xg -Nline

並列数

1プロセス1スレッド

ラージページ -p 256MB -d 256MB -h 256MB -s
256MB -t 256MB
サイズ

 全体実行時間

分析対象

インデックス
作成時間[s]アライメント1
実行時間[s]アライメント２
実行時間[s]マッピング
実行時間[s]

9,924

56,206

37,84534,9173

219 / 253

Copyright 2014 FUJITSU LIMITED分析のためのソース変更について
 目的
 実行時間短縮により効率的に分析を行うため

 ソース変更内容
 繰り返し部(bwtaln.cのline180-２２６)の繰り返し数が３回目に入った直後に強制的にループを抜ける処理の追加
ソース変更前void bwa_aln_core(const char *prefix, const char *fn_fa, const gap_opt_t *opt)
中略while ((seqs = bwa_read_seq(ks, 0x40000, &n_seqs, opt‐>mode, opt‐>trim_qual)) != 0) {tot_seqs += n_seqs;
中略bwa_free_read_seq(n_seqs, seqs);
fprintf(stderr, "[bwa_aln_core] %d sequences have been processed.¥n", tot_seqs);}

ソース変更後void bwa_aln_core(const char *prefix, const char *fn_fa, const gap_opt_t *opt){
int fj_iter=0;
中略
while ((seqs = bwa_read_seq(ks, 0x40000, &n_seqs, opt‐>mode, opt‐>trim_qual)) != 0) {tot_seqs += n_seqs;//fj >
fj_iter++;
if (fj_iter ==3 ) break;//fj <
中略bwa_free_read_seq(n_seqs, seqs);
fprintf(stderr, "[bwa_aln_core] %d sequences have been processed.¥n", tot_seqs);
}

変更前
変更後

4

繰り返し数
252
2

Copyright 2014 FUJITSU LIMITED

プロファイラ結果
 アライメント１
 サンプリング間隔は10msec
全体実行
時間[s]
512.01

MFlops
0.12

Flops
ピーク比
0.00%

ＭＩＰＳ
1,616.94

コスト分布(関数単位)
関数名__GI_memcpy
bwt_match_gap
bwt_2occ4
bwt_match_exact_alt
bwt_2occ
合計

MIPS
ピーク比
21.87%

Memスループット(MB/s)
347.82

Mem
ピーク比
0.41%

コスト分布(ループ単位)

開始行 終了行 実行時間[s] 割合(%)--129.61 26.08
104
264121.22 24.39
177
214
120.69 24.29
235
250
86.28 17.36
116
151
29.55
5.95
487.35 98.07

関数名
開始行
終了行 実行時間[s] 割合(%)
bwt_2occ4 (*1)
170
171
30.84
6.21
bwt_2occ4
202
203
27.05
5.44
bwt_match_exact_alt (*1)
105
106
23.72
4.77
bwt_match_exact_alt (*1)
137
138
15.08
3.03
bwt_match_gap
129
147
12.45
2.51
bwt_2occ
105
106
8.96
1.80
bwt_match_gap
246
252
6.73
1.35
bwt_2occ4
208
208
5.86
1.18
合計
130.69 26.30• 高コスト関数にＩＯは含まれない。
したがって、IOは2%未満。
*1 インライン展開された関数からの呼び出し• 浮動小数点演算はほぼ零• 関数単位で見るとコストは集中しているが、ループ単位では分散→ ループ以外の処理もコストが高い• __GI_memcpyの99%以上はbwt_match_gapからの呼び出し。
5

220 / 253

Copyright 2014 FUJITSU LIMITEDプロファイラ結果 アライメント2
 サンプリング間隔は10msec
全体実行
時間[s]
312.52

MFlops

Flops
ピーク比

0.16

0.00%

ＭＩＰＳ

MIPS
ピーク比

1,304.24

コスト分布(関数単位)
関数名
bwt_match_exact_alt__GI_memcpy
bwt_match_gap
bwt_2occ4
bwt_2occ
合計

17.64%

Memスループット(MB/s)
434.20

Mem
ピーク比
0.51%

コスト分布(ループ単位)

開始行 終了行 実行時間[s] 割合(%)
235250
144.31 47.96--50.45 16.77
104
264
49.40 16.42
177
214
33.57 11.16
116
151
14.72
4.89
292.45 97.19

関数名
開始行
終了行 実行時間[s] 割合(%)
bwt_match_exact_alt(*1)
137
138
32.16 10.69
bwt_match_exact_alt(*1)
105
106
31.17 10.36
bwt_2occ4 (*1)
170
171
13.39
4.45
bwt_match_gap
129
147
4.82
1.60
bwt_2occ4
202
203
4.50
1.49
bwt_match_gap
246
252
4.40
1.46
bwt_2occ
105
106
3.93
1.31
bwt_match_exact_alt
240
247
3.87
1.29
合計
98.25 32.65• アライメント１とほぼ同じ傾向• 高コスト関数にＩＯは含まれない。
*1 インライン展開された関数からの呼び出ししたがって、ＩＯは3%未満。
• アライメント１との違いは、関数･ループ単位共にbwt_match_exact_altのコストが上昇している点。アライメント2では1よりもbwt_match_exact_altの呼び出し回数が多い。詳細は次ページ参照。
6

Copyright 2014 FUJITSU LIMITED

関数呼び出し・ループ構造
 関数呼び出し構造

精密ＰＡ測定区間

0 main1 +-- bwa_aln
2 +--bwa_aln_corewhile(回転数:2)(*1)
3+-- bwa_cal_sa_reg_gap
for(回転数:262,144)4+-- bwt_match_gap
while(回転数:平均730.49)
5+-- bwt_match_exact_alt
for(回転数：平均4.78)
6+-- bwt_2occ(*2)
for(回転数:平均6.86)
7+-- bwt_occ(*2)
for(回転数:平均2.98)
5+-- bwt_2occ4
for(回転数：平均3.13)
6+-- bwt_occ4(*2)
for(回転数：平均6.89)
後略

呼び出し回数 呼び出し回数
アライメント１ アライメント２
main1
1
bwa_aln1
1
bwa_aln_core
11
bwa_cal_sa_reg_gap
2(*1)
2(*1)
bwt_math_gap
524,288524,288bwt_2occ4
875,091,049 215,852,571
bwt_occ4 (*2)
310,014,082 128,954,096
bwt_mathc_exact_alt
62,030,259 151,061,822
bwt_2occ (*2)
316,942,742 548,009,172
bwt_occ (*2)
118,684,080 162,986,465
関数名*1 ソース変更による変更あり。オリジナルでは252回。
*2 インライン展開対象

 呼び出し回数の多い関数の一部はasisでインライン展開済み→ソース修正でbwt_2occ4, bwt_mathc_exact_altのインライン展開を試行したが性能向上無し
 呼び出し回数の多い関数のループは回転数が小さく1回あたりの実行時間が短いため精密ＰＡ採取不可。
7221 / 253

Copyright 2014 FUJITSU LIMITED精密ＰＡ情報
 測定区間 bwt_match_exact_altおよびbwt_occ4呼び出しを含むループ
start_collection("bwt_match_gap");
while (stack‐>n_entries) {中略
if (i == 0) hit_found = 1;
else if (m == 0 && (e.state == STATE_M || (opt‐>mode&BWA_MODE_GAPE) || e.n_gape == opt‐>max_gape)) {if (bwt_match_exact_alt(bwt, i, str, &k, &l)) hit_found = 1;
else continue; // no hit, skip}
中略bwt_2occ4(bwt, k ‐ 1, l, cnt_k, cnt_l); // retrieve Occ values}
stop_collection("bwt_match_gap");*_n_aln = n_aln;

実行時間 (sec)
420.98[秒]
4.5E+02
4.0E+02
3.5E+02
3.0E+02

MFLOPS

MIPS
0

1829

ロードストア 浮動小数点演算
命令数
命令数
1.74293E+11
0.00E+00

その他
命令数
5.25E+11

有効総命令数7.70E+11

L1D ミス dm率 L2 ミス dm 率(/L1D ミス数)(/L2 ミス数)
92.91%
84.66%

2.5E+02
2.0E+02
1.5E+02
1.0E+02
5.0E+01
0.0E+00
bwt_match_gap

・整数演算比率が高い
・アクセス待ちが多いがバンド幅
ネックではない・プリフェッチが効いていない8

Copyright 2014 FUJITSU LIMITED

ソースコード分析 bwt_match_exact_alt

赤字:インライン展開対象
青字：Define文

int bwt_match_exact_alt(const bwt_t *bwt, int len, const ubyte_t *str, bwtint_t *k0,
bwtint_t *l0){
int i;
bwtint_t k, l, ok, ol;
k = *k0; l = *l0;for (i = len ‐ 1; i >= 0; ‐‐i) {ubyte_t c = str[i];if (c > 3) return 0; // there is an N here. no match
bwt_2occ(bwt, k ‐ 1, l, c, &ok, &ol);k = bwt‐>L2[c] + ok + 1;
l = bwt‐>L2[c] + ol;
if (k > l) return 0; // no match}*k0 = k; *l0 = l;return l ‐ k + 1;}

コスト8位ループ(1.35%, 平均4.78回)

Ｌ２はリストアクセス(要素数5)

inline void bwt_2occ(const bwt_t *bwt, bwtint_t k, bwtint_t l, ubyte_t c, bwtint_t *ok,bwtint_t *ol){bwtint_t _k, _l;if (k == l) {*ok = *ol = bwt_occ(bwt, k, c);return;}_k = (k >= bwt‐>primary)? k‐1 : k;_l = (l >= bwt‐>primary)? l‐1 : l;if (_l/OCC_INTERVAL != _k/OCC_INTERVAL || k == (bwtint_t)(‐1) || l == (bwtint_t)(‐1)) {*ok = bwt_occ(bwt, k, c);*ol = bwt_occ(bwt, l, c);} else {bwtint_t m, n, i, j;
uint32_t *p;
if (k >= bwt‐>primary) ‐‐k;if (l >= bwt‐>primary) ‐‐l;n = (p = bwt_occ_intv(bwt, k))[c];続く9222 / 253

Copyright 2014 FUJITSU LIMITEDソースコード分析 bwt_match_exact_alt

赤字:インライン展開対象
青字：Define文

p += 4;// calculate *ok
j = k >> 5 << 5;
for (i = k/OCC_INTERVAL*OCC_INTERVAL; i < j; i += 32, p += 2)n += __occ_aux((uint64_t)p[0]<<32 | p[1], c);m = n;

コスト4位ループ(3.03%, 平均6.86回)
ビット演算2回、整数演算1回、連続アクセス(p)n += __occ_aux(((uint64_t)p[0]<<32 | p[1]) & ~((1ull<<((~k&31)<<1)) ‐ 1), c);
if (c == 0) n ‐= ~k&31; // corrected for the masked bits *ok = n;// calculate *ol
j = l >> 5 << 5;
for (; i < j; i += 32, p += 2)
m += __occ_aux((uint64_t)p[0]<<32 | p[1], c);}}

ビット演算8回、整数演算１回
コスト19位ループ(0.02%、回転数未調査)
ビット演算2回、整数演算1回、連続アクセス(p)m += __occ_aux(((uint64_t)p[0]<<32 | p[1]) & ~((1ull<<((~l&31)<<1)) ‐ 1), c);
if (c == 0) m ‐= ~l&31; // corrected for the masked bits
*ol = m;

ビット演算8回、整数演算１回

static inline int __occ_aux(uint64_t y, int c){
y = ((c&2)? y : ~y) >> 1 & ((c&1)? y : ~y) & 0x5555555555555555ull;
y = (y & 0x3333333333333333ull) + (y >> 2 & 0x3333333333333333ull);
return ((y + (y >> 4)) & 0xf0f0f0f0f0f0f0full) * 0x101010101010101ull >> 56;}

最内ループから呼び出し。
ビット演算13回、整数演算3回

inline bwtint_t bwt_occ(const bwt_t *bwt, bwtint_t k, ubyte_t c){bwtint_t n, l, j;
uint32_t *p;
if (k == bwt‐>seq_len) return bwt‐>L2[c+1] ‐ bwt‐>L2[c];if (k == (bwtint_t)(‐1)) return 0;
if (k >= bwt‐>primary) ‐‐k; // because $ is not in bwt// retrieve Occ at k/OCC_INTERVAL
n = (p = bwt_occ_intv(bwt, k))[c];続く10

Copyright 2014 FUJITSU LIMITED

ソースコード分析 bwt_match_exact_alt

赤字:インライン展開対象
青字：Define文

p += 4; // jump to the start of the first BWT cellj = k >> 5 << 5;
for (l = k/OCC_INTERVAL*OCC_INTERVAL; l < j; l += 32, p += 2)n += __occ_aux((uint64_t)p[0]<<32 | p[1], c);// calculate Occ
n += __occ_aux(((uint64_t)p[0]<<32 | p[1]) & ~((1ull<<((~k&31)<<1)) ‐ 1), c);
if (c == 0) n ‐= ~k&31; // corrected for the masked bits}

コスト3位ループ(4.77%, 平均2.98回)
ビット演算2回、整数演算1回、連続アクセス(p)ビット演算8回、整数演算1回

return n;#define bwt_occ_intv(b, k) ((b)‐>bwt + (k)/OCC_INTERVAL*12)

 最内ループのメモリアクセスは連続アクセス。
 最内ループの1回転辺りの演算数は、一定。
• 64バイト型のビット演算15回(and 7, or 1, not 2, 右シフト 4, 左シフト 1)、
整数演算4回(和算3回、積算1回)、ループ制御変数インクメント

 最内ループは演算数19に対してストリーム数1。

11

223 / 253

Copyright 2014 FUJITSU LIMITEDソースコード分析 bwt_2occ4
inline void bwt_2occ4(const bwt_t *bwt, bwtint_t k, bwtint_t l, bwtint_t cntk[4],bwtint_t cntl[4]){bwtint_t _k, _l;if (k == l) {bwt_occ4(bwt, k, cntk);
memcpy(cntl, cntk, 4 * sizeof(bwtint_t));
return;}_k = (k >= bwt‐>primary)? k‐1 : k;_l = (l >= bwt‐>primary)? l‐1 : l;if (_l/OCC_INTERVAL != _k/OCC_INTERVAL || k == (bwtint_t)(‐1) || l == (bwtint_t)(‐1)) {bwt_occ4(bwt, k, cntk);
bwt_occ4(bwt, l, cntl);} else {bwtint_t i, j, x, y;
uint32_t *p;
int cl[4];if (k >= bwt‐>primary) ‐‐k; // because $ is not in bwt
if (l >= bwt‐>primary) ‐‐l;cl[0] = cl[1] = cl[2] = cl[3] = 0;p = bwt_occ_intv(bwt, k);memcpy(cntk, p, 4 * sizeof(bwtint_t));p += 4;// prepare cntk[]
j = k >> 4 << 4;
for (i = k / OCC_INTERVAL * OCC_INTERVAL, x = 0; i < j; i += 16, ++p)x += __occ_aux4(bwt, *p);y = x;
x += __occ_aux4(bwt, *p & ~((1U<<((~k&15)<<1)) ‐ 1)) ‐ (~k&15);// calculate cntl[] and finalize cntk[]
j = l >> 4 << 4;
for (; i < j; i += 16, ++p) y += __occ_aux4(bwt, *p);y += __occ_aux4(bwt, *p & ~((1U<<((~l&15)<<1)) ‐ 1)) ‐ (~l&15);
memcpy(cntl, cntk, 16);
cntk[0] += x&0xff; cntk[1] += x>>8&0xff; cntk[2] += x>>16&0xff; cntk[3] += x>>24;
cntl[0] += y&0xff; cntl[1] += y>>8&0xff; cntl[2] += y>>16&0xff; cntl[3] += y>>24;}}

赤字:インライン展開対象
青字：Define文コスト2位ループ(5.44%, 平均3.13回)
整数演算1回、連続アクセス(p)コスト9位ループ(1.17%, 回転数未調査)
ビット演算7回、整数演算3回続く
12

Copyright 2014 FUJITSU LIMITED

ソースコード分析 bwt_2occ4
inline void bwt_occ4(const bwt_t *bwt, bwtint_t k, bwtint_t cnt[4]){bwtint_t l, j, x;
uint32_t *p;
if (k == (bwtint_t)(‐1)) {memset(cnt, 0, 4 * sizeof(bwtint_t));
return;}if (k >= bwt‐>primary) ‐‐k; // because $ is not in bwt
p = bwt_occ_intv(bwt, k);memcpy(cnt, p, 16);
p += 4;
j = k >> 4 << 4;
for (l = k / OCC_INTERVAL * OCC_INTERVAL, x = 0; l < j; l += 16, ++p)x += __occ_aux4(bwt, *p);x += __occ_aux4(bwt, *p & ~((1U<<((~k&15)<<1)) ‐ 1)) ‐ (~k&15);
cnt[0] += x&0xff; cnt[1] += x>>8&0xff; cnt[2] += x>>16&0xff; cnt[3] += x>>24;}#define bwt_occ_intv(b, k) ((b)‐>bwt + (k)/OCC_INTERVAL*12)#define __occ_aux4(bwt, b)¥((bwt)‐>cnt_table[(b)&0xff] + (bwt)‐>cnt_table[(b)>>8&0xff]¥+ (bwt)‐>cnt_table[(b)>>16&0xff] + (bwt)‐>cnt_table[(b)>>24])

赤字:インライン展開対象
青字：Define文コスト1位ループ(6.21%, 平均6.86)
整数演算1回、連続アクセス(p)ビット演算7回、整数演算3回最内ループから呼び出し。ビット演算
6回、整数演算3回、cnt_tableはリストアクセス(要素数256）

 最内ループで4回リストアクセス(bwt->cnt_table)あり。要素数は256でＬ１キャッシュに収まるサイズ。
 最内ループの1回転辺りの演算数は、一定。
• 64バイト型のビット演算6回(and 3, 右シフト 3)、整数演算4回(和算4回)、ループ制御変数インクメント

 最内ループは演算数10に対して、ストリーム数4。
13

224 / 253

Copyright 2014 FUJITSU LIMITEDソースコード分析 bwt_match_gap(__GI_memcpy関連処理)

赤字:__GI_memcpy関連処理

bwt_aln1_t *bwt_match_gap(bwt_t *const bwts[2], int len, const ubyte_t *seq[2],bwt_width_t *w[2],bwt_width_t *seed_w[2], const gap_opt_t *opt, int *_n_aln, gap_stack_t*stack){int best_score = aln_score(opt‐>max_diff+1, opt‐>max_gapo+1, opt‐>max_gape+1, opt);
int best_diff = opt‐>max_diff + 1, max_diff = opt‐>max_diff;
int best_cnt = 0;
int max_entries = 0, j, _j, n_aln, m_aln;bwt_aln1_t *aln;m_aln = 4; n_aln = 0;aln = (bwt_aln1_t*)calloc(m_aln, sizeof(bwt_aln1_t));
中略while (stack‐>n_entries) {中略
if (do_add) { // append
bwt_aln1_t *p;
gap_shadow(l ‐ k + 1, len, bwt‐>seq_len, e.last_diff
if (n_aln == m_aln) {m_aln <<= 1;
aln = (bwt_aln1_t*)realloc(aln, m_aln * sizeof(bwt_aln1_t));memset(aln + m_aln/2, 0, m_aln/2*sizeof(bwt_aln1_t));}p = aln + n_aln;p‐>n_mm = e.n_mm; p‐>n_gapo = e.n_gapo; p‐>n_gape = e.n_gape; p‐>a = a;p‐>k = k; p‐>l = l;p‐>score = score;++n_aln;}中略}}*_n_aln = n_aln;//fprintf(stderr, "max_entries = %d¥n", max_entries);
return aln;

初めに4要素の構造体(bwt_aln1_t)で領域確保および0で初期化。構造体のサイズは16バイト。

領域が足りなくなったら、2倍の領域をreallocで再確保。拡大領域をmemcpyで0初期化。

構造体の必要要素数が1増加

確保した領域の先頭アドレスが戻り値

14

Copyright 2014 FUJITSU LIMITED

ソースコード分析 bwt_match_gap(__GI_memcpy関連処理)
 __GI_memcpy関連の呼び出し回数を調査
コピーサイズ 呼び出し回数 呼び出し回数[byte]
アライメント1 アライメント2
calloc64524,288524,288
128
42,66259,379256
36,39552,211
512
23,18635,272
1,024
13,21020,420realloc
memset
2,048
5,549
8,653
4,096
1,120
1,438
8,192
48
56
16,38401

関数名

 約9割のケースで初めに確保(calloc)した領域から拡張無し。
 初めに確保する領域を大きく(2048バイト)する高速化を試行したが性能向上無し。 callocの呼び出し回数を減らす必要あり。

15

225 / 253

Copyright 2014 FUJITSU LIMITED

まとめ 関数単位ではコスト集中
 ユーザ定義の４関数で97％。
 高コスト関数にＩＯは含まれないためIOは3%未満。

 ループ単位ではコスト分散
 上位8ループで約30%。

 整数演算がメイン
 精密ＰＡ結果より70%が整数演算関連の命令。浮動小数点演算は零。
 精密ＰＡ結果よりプリフェッチ効果なし。
 ソースコード分析により高コストループは以下の2パターン。
1. ビット演算15 + 整数演算４に対してメモリアクセスは連続でストリーム数1
2. ビット演算6 + 整数演算4に対してリストアクセスでストリーム数4

 calloc,reallocによる初期化･領域拡張のコストが高い。
 bmt_match_gapから呼び出し。
アライメント1では26%、アライメント2では11%16

Copyright 2014 FUJITSU LIMITED

17

Copyright 2014 FUJITSU LIMITED

226 / 253

SS研 ポストペタアプリ性能WG資料

BWAのFX100性能報告

2015年12月3日
富士通株式会社
ＴＣソリューション事業本部
TCフロンティアセンター
Copyright 2015 FUJITSU LIMITED

目次
 アプリ概要
 評価動作環境、実行結果
 プロファイラ結果
 スレッド数による性能、使用メモリ量の変化
 ＦＸ１００精密ＰＡ情報 プリフェッチが効かない理由
 手動プリフェッチの可能性
 まとめ

1

227 / 253

Copyright 2015 FUJITSU LIMITEDアプリ概要 アプリ概要
 アプリ名：bwa (Burrows-Wheeler Alignment Tool)

 処理概要： ゲノムマッピングを行うツール。複数回プログラム実行が必要。
インデックスファイル作成

アライメント実行1
アライメント実行2

マッピング実行 バージョン： 0.5.10 (最新版は0.7.12)
 並列化手法: pthredによる並列化。ＭＰＩ並列は無し。
 記述言語:本報告で評価C

 コード行数: 8940
 入力(NGS)データ： 日本人の公開ゲノムデータ

2

Copyright 2015 FUJITSU LIMITED

評価動作環境・全体実行時間
 評価動作環境

 評価条件

システム

FX10

FX100

実行コマンド./bwa aln

周波数1.85GHz

1.975GＨＺ

入力ファイル

Simd幅

2

4

DRR000606_1.fa
stq

評価繰り返し数

オプション-Kfast -Xg Nline-Kfast -Xg Nline

100(コスト分布,
スケーラビリティ)
2(精密PA）

並列数

1コア

1コア

IO量

8625.1 MB

ただし並列性能調査時
は8,16,32コアも評価

 実行時間
システム

FX10

FX100

性能
向上率

実行時間[s]16885.48(Elapse)17576.08

0.96

実行時間[s]16801.84(User)

17176.89

0.98

3228 / 253

・FX10と比較してFX100では(ElapseUser)時間(=IO時間)が大きい。
・IO時間を除いてもFX10→FX100で0.98倍性能劣化

Copyright 2015 FUJITSU LIMITED

関数呼び出し・ループ構造
 呼び出し構造
精密ＰＡ測定区間

0 main1 +-- bwa_aln
2 +--bwa_aln_corewhile(回転数:2 or 100)
3+-- bwa_cal_sa_reg_gap
for(回転数:262,144)4+-- bwt_match_gap
while(回転数:平均730.49)
5+-- bwt_match_exact_alt
for(回転数：平均4.78)
6+-- bwt_2occ
for(回転数:平均6.86)
7+-- bwt_occ
for(回転数:平均2.98)
5+-- bwt_2occ4
for(回転数：平均3.13)
6+-- bwt_occ4
for(回転数：平均6.89)
後略

２回： 精密PA、プリフェッチ調査
100回：コスト分布、並列性能調査

インライン展開対象

4

Copyright 2015 FUJITSU LIMITED

プロファイラ結果
 FX10コスト分布(関数単位)関数名
bwt_2occ4
bwt_match_gap
bwt_match_exact_alt
bwt_2occ
合計

開始行
182
104
254
116
-

コスト分布(ライン単位)
終了行
233
264
269
151
-

実行時間[s]割合(%)

7200.04 42.85
4430.56 26.37
3811.79 22.69
1005.05
5.98
16447.44 97.89

 FX100

コスト分布(関数単位)関数名
bwt_2occ4
bwt_match_gap
bwt_match_exact_alt
bwt_2occ
合計

開始行
182
104
177
116
-

関数名
bwt_2occ4
bwt_2occ4
bwt_2occ4
bwt_2occ4
bwt_match_exact_alt
bwt_match_gap
bwt_match_exact_alt
合計

開始行 実行時間[s] 割合(%)
170
1526.18 9.08
211
1318.41 7.85
1761033.61 6.15
218
960.20 5.71
105
780.96 4.65
51
663.56 3.95
137
548.96 3.27
6831.87 40.66

コスト分布(ライン単位)
終了行
233
266
214
151
-

割合
実行時間[s](%)
7647.314173.703982.811089.7116893.52

関数名

44.49
24.28
23.17
6.34
98.28

 結果

bwt_2occ4
bwt_2occ4
bwt_match_exact_alt
bwt_2occ4
bwt_2occ4
bwt_match_exact_alt
bwt_match_gap
合計

開始行
170
211
105
176
218
137
51
-

割合
(%)
2264.77 13.18
1973.11 11.48
1558.28 9.07
985.76 5.73
722.84 4.21
576.79 3.36
517.34 3.01
8598.89 50.03

実行時間[s] FX10, FX100ともに上位4関数でほぼ100%
 ライン単位では上位7処理で約50%
5229 / 253

Copyright 2015 FUJITSU LIMITEDFX100スレッド並列性能・メモリ使用量
 実行結果 並列性能 1スレッド実行→32スレッド実行で13.79倍性能向上
 16スレッド実行→32スレッド実行で1.44倍性能向上→理想値より性能向上率は低いが並列性は高い

 メモリ使用量
 1スレッド実行→３２スレッド実行で1.34倍増加
6

Copyright 2015 FUJITSU LIMITED

精密ＰＡ比較
 評価区間はbwt_match_gap
環境[秒]
4.5E+02

FX100
FX10

4.0E+02

メモリビジー L2エンジン L1エンジン L1D ミス dm率 L2 ミス dm 率率
ビジー率
ビジー率 (/L1D ミス数) (/L2 ミス数)
0.55%
0.31%
17.91%
95.98%
90.83%
0.55%
0.45%
21.75%
92.98%
80.69%

3.5E+02
3.0E+02

命令コミット

2.5E+02

整数レジスタ書き込み制約

2.0E+02

整数ロードＬ１Ｄアクセス待ち

1.5E+02

ミスの大半がdmミス→プリフェッチが効いていない

整数ロードL2アクセス待ち

1.0E+02

整数ロードキャッシュアクセス待ち

5.0E+01
整数ロードメモリアクセス待ち

0.0E+00
FX100

FX10

 メモリ、キャッシュビジー率が低い
 メモリアクセス待ち、キャッシュアクセス待ちの割合が高い→プリフェッチが効いていない
7

230 / 253

Copyright 2015 FUJITSU LIMITEDプリフェッチが効かない理由 ポインタ変数が指すアドレスが連続でないため(インダイレクト)#define OCC_INTERVAL 0x80
#define bwt_occ_intv(b, k) ((b)->bwt + (k)/OCC_INTERVAL*12)中略
157 inline void bwt_occ4(const bwt_t *bwt, bwtint_t k, bwtint_t cnt[4])158 {159 bwtint_t l, j, x;
160 uint32_t *p;
161 int i;
162 if (k == (bwtint_t)(-1)) {163 memset(cnt, 0, 4 * sizeof(bwtint_t));
164 return;165 }166 if (k >= bwt->primary) --k; // because $ is not in bwt
167 p = bwt_occ_intv(bwt, k);
168 // memcpy(cnt, p, 16);169 for(i=0;i<4;i++){
170 cnt[i]=*p;
171 p++;
172 }

コスト分布1位の処理

前回呼び出しから2.7GB離れたアドレス参照

 最大で2.7ＧＢはなれたアドレスを参照
 ポインタ変数p移動距離に規則性がないように見える 繰り返し毎にどのアドレスを参照するか事前にわかれば手動でプリフェッチ発
行可能
8Copyright 2015 FUJITSU LIMITED

手動プリフェッチの可能性について ポインタpの参照先を事前に把握可能か？
 ポインタｐの参照先更新がいつ行われるか調査
ポインタpの参照先更新の概略
bwt_match_gap
while{
gap_pop(stack, &e);

構造体eの値更新

k = e.k;k=構造体eのローカル変数

bwt_2occ4(bwt, k - 1, l, cnt_k, cnt_l);pの参照先更新
更新先は変数kによって決定
構造体stackの値更新

中略
gap_push(stack, a, i + 1, k, l, ･･･);}

 ポインタpの参照先を決定する変数kはpの参照先更新の直前に定義
 kの定義する構造体eはその直前に値更新。e=構造体stackのローカル構造体。
 構造体stackは前の繰り返し最後に値更新。

ポインタpの参照先を事前に把握は不可!!
→手動プリフェッチ設定は不可
9231 / 253

Copyright 2015 FUJITSU LIMITEDまとめ bwa単体性能
 ＦＸ１０と比較してＦＸ１００において性能向上しない→ボトルネックはメモリ、キャッシュアクセスのレイテンシ→ポインタ変数がインダイレクトアクセスでプリフェッチが効かないことが原因→プログラム構造上プリフェッチを効かせる事は難しい。

 bwa並列性能
 並列実行によるメモリ使用量は微増、並列性能は比較的良好→メニーコアによる並列実行に適性あり。

10

Copyright 2015 FUJITSU LIMITED

11

Copyright 2015 FUJITSU LIMITED

232 / 253

2.12 FMO プログラム ABINIT-MP の富士通系マシンでの性能評価
立教大学

理学部 化学科
望月祐志【序】

巨大分子の“分割統合”系の種々の量子化学計算法[1]の中で、フラグメント分子軌道(FMO)法[2-4]は方法論的な発展の多様性と応用事例の豊かさの点で、最も成功している手法の一つです。手法上の大きな特徴は、対象系をフラグメント単位に分割し、環境静電ポテンシャル(ESPの印加条件でフラグメント単体(モノマー：1 体)、フラグメント対(ダイマー：2 体)…の計算を並列実行することで、生来的に高い並列処理親和性を有しています。FMO 法では、系全体の分極や電子の非局在化などの量子論的な効果が取り込める点で古典(MM)や量子/古典混成)(QM/MM)とは異なります。また、全系をフルに QM で扱う最近の手法(いわゆるオーダーN 系など)とも違い、
フラグメント間相互作用エネルギー(IFIE や PIE と呼ばれる)などの「物理化学的な内部情報」が得られるので、FMO 法は計算対象に対する解析ツールとしての機能も併せ持つことにもなります。
FMO 法のプログラムとしては、米国の Iowa 州立大の Gordon 研/産総研の D.G.Fedorov 氏らが手掛けている GAMESS-US[1,3]が機能豊富でメジャーな存在ではありますが、私たちが自主開発してきました ABINIT-MP[2,4,5]、長崎大の石川岳志氏による PAICS[6]もあります。これまで
FMO 計算は、上述のフラグメント間相互作用エネルギーをベースにタンパク質-リガンド複合系などを対象に創薬や生物物理のバイオ系分野で主に使われてきました[2-4]。しかし最近では、ナノバイオ・非バイオ系のものづくり分野への適用など応用範囲が広がってきています。特にABINIT-MP は、ポスト「京」のプロジェクト(フラッグシップ 2020)では、ナフィオンなどのイ
オン交換性高分子と水の界面の相互作用解析などに粗視化シミュレーションと連携して利用されることになっています。
これ以下、本稿では ABINIT-MP の富士通系マシン(「京」、FX-10、FX-100)での ABINIT-MPによる FMO 計算の性能評価について概要をまとめます。詳細なタイミングデータやグラフなど
は、別提出の資料をご参照いただければと思います。
【FMO 計算の流れ】 FMO 計算は多数のステップから構成されており、各々で演算のタイプも異なります[2-4]。ここでは、ジョブとして最もよく利用される 2 体フラグメント展開による 2 次
摂動論(FMO-MP2：FMO2-MP2 として 2 体を強調する場合もあり)の流れについて概説します。
先ずフラグメントのモノマー計算では、各フラグメントに対して ESP を印加した条件で分子軌
道の最適化をハートリーフォック(HF)レベルで行います。各フラグメントは複数のコアで並列計算され、フラグメントモノマーのリストもまた並列化されますので並列処理としては 2 階層となります。フラット MPI でも出来ますが、「京」や FX-10 などの富士通系マシンではフラグメント
内の処理を OpenMP でスレッド並列し、フラグメントのリストを MPI でプロセス並列する混成型で実行することが普通です。各フラグメントの HF 計算では添字を 4 つ有する基底関数添字の2 電子積分を生成し、密度行列と縮約して Fock 行列を構築するステップがコストを決しており、フラグメント内で自己無撞着場(SCF)条件が成立するまで構築と対角化が反復されます。また、
Fock 行列要素に加算される ESP 項の計算も時間がかかりますので、幾つかの近似を要求精度に

233 / 253

応じて導入しています。各フラグメントの電子分布は ESP を通じて互いに依存しているため、系全体として自己無撞着な電荷場(SCC)を満たすようにサイクルとして繰り返す必要があり、ここ
で分極効果が取り込まれます。ただ、モノマーはノード内でのみ OpenMP で並列化されるので、系が小さい・フラグメント数が少ない場合には多数のノードが「遊ぶ」状態となることには注意が要ります。一旦 SCC 条件が満たされれば、各フラグメントで MP2 計算のステップに進みます
が、処理の本質は基底関数添字から分子軌道添字への 4 段階の線形変換処理ですので DGEMM に代表される BLAS で効率よく処理が出来ます(HF と違って繰り返しの必要は無)。
フラグメントモノマーのステージが終われば、ダイマーの計算に進みます。ここでは、ESP はモノマー段階で決まったものを使うので全体での繰り返しは不要で、近接モノマーの組から成る
ダイマーのタスクリストに応じて HF/MP2 計算が進行し、電子の非局在化が取り込まれます。ダ
イマーのリストは組み合わせとなりますので、ノードを有効利用することが出来ます。モノマーと同様、ダイマーも OpenMP でノード内で並列処理されます(コストはモノマーよりも大)。また、離れたモノマーから成るダイマーは HF を省いて静電近似で済ませて高速化を図っています。
FMO2-MP2 ジョブのコストの増加は、対象分子系の形状にも依りますが、実質的には系の大きさに対して 2 乗より低い依存性となり、FMO 計算の実用性・汎用性の高さに直結しています。
【ABINIT-MP の現況】 東大生産研のサイト[5]では、2014 年の 7 月末から Ver.7 の Intel Xeon
用の ABINIT-MP[4]のバイナリがフリーでダウンロード可能です。また、「京」では Ver.6+が 2014
年度末に共用ライブラリとして登録され、創薬コンソーシアムなどで利用されています[8]。
ABINIT-MP では、フラグメントのトリマーとテトラマーまで含める 4 体展開による FMO4 法[7]に一つの特徴があり、高い空間解像度を持つ相互作用解析や固体(バンドギャップは有)のモデ
リングなどが可能です。種々の工夫により、FMO4-MP2 の FMO2-MP2 に対する相対的なコストは最大で 10 倍程度で済むようになっています。もう一つ特徴的なのは、2 電子積分のコレスキー
分解(CD[9])によって計算時間の短縮が図れることです。CD では、4 添字のテンソルと見なせる
2 電子積分を 3 添字のテンソルの積和の形に分解して、BLAS での処理を積極的に活用することで加速を得ます。富士通系では DGEMM が特に高速であるため、CD の効果は大きいと期待されます。ただ、CD では分解補助基底が基底関数の積に取られるため、最適化された補助関数を別途用意する恒等分解(RI)[10]に比すとコスト高になりがちで、計算精度は若干落ちますが 1 中心(1C)制限などを課すことも多々あります。
ABINIT-MP Ver.7 のその他の機能では、3 次摂動(MP3)エネルギー[11]、MP2 レベルのエネル
ギー微分を利用した部分構造最適化

三次元構造可視化と分子構造の編集
ABINIT-MP入力ファイルの作成[12]や直接分子動力学(FMO-MD)[13]、軌道レベルでの相互作用解析などがあViewer も提供されていますので、フラグメント情報などの入力データのセッ
トアップ、ならびに出力データとして得BioStation
Viewerユーザー

ります。また、専用 GUI の BioStation

三次元立体構造データ
PDBデータ（26,000件突破）
ホモロジーモデリング等による予測構造

ABINIT-MPによる高精度量子化学計算
蛋白質－化合物ドッキング解析

FMO計算

ABINIT-MPられる相互作用エネルギー(IFIE)のリ

生体系の応用計算
核内受容体
プロテアーゼと阻害剤
抗原抗体反応DNAの化学反応
その他の生体高分子系

FMO計算結果の可視化・解析

234 / 253

ストの可視的な理解が容易に行えます。上図は、タンパク質の FMO 計算による解析のワークフ
ローを例示したものですが、アミノ酸残基数が数十よりも多い場合、結果の把握には GUI の利用は不可欠となってきます。もちろん、BioStation Viewer は非バイオ系の固体や分子性結晶に対しても使うことが出来ます[4]。
【「京」でのベンチマーク結果】 「京」での実行テストは、2012 年の夏から、それまで ABINIT-MPがプラットフォームとしてきた Intel x64 系のサーバや NEC の SX の実行結果と数値的に一致するかどうかの検証から始めました。Ver.6 を使い、OpenMP/MPI 混成並列で本格的にベンチマークを行ったのは 2014 年度ですが、d 関数に関する積分生成ルーチン群を Opt3 でコンパイルすると値が不正となる障害があり、当該箇所のみ Opt2 適用とする暫定措置でデータを取得しました(d関数は 6-31G*や cc-pVDZ 基底で含まれます)。
先ず、24 ノードで測定した小タンパク質の FMO2-MP2
ジョブのタイミングを右表に示します。TrpCage は 20 残基で主鎖分割して 20 フラグ
メント、粒度を揃えたモデル
タンパク質の Trp23His は 24
フラグメントです(FMO の結合切断の都合から 24 番目の残基は小さ目でバランスさせます)。2 電子積分を CD で扱
い、HF ステップも BLAS で処理する方が高効率となり、Basis set

TEI treatment

Time (Min) Eff. (%) Time (Min) Eff. (%)
TrpCage (20 frag.)
Trp23His
6-31G
Regular
12.6
2.3
36.8
2.53
CD/MP2
8.2
4.4
19.5
7.13
CD/MP2&HF
5.7
15.6
14.6
18.35
1C-CD/MP2
7.6
2.5
16.7
2.97
1C-CD/MP2&HF
3.0
8.8
8.2
9.66
6-31G*
Regular
38.2
3.0
136.9
3.43
CD/MP2
28.0
6.6
96.0
8.87
CD/MP2&HF
18.9
29.0
44.6
31.89
1C-CD/MP2
25.9
3.4
84.7
3.88
1C-CD/MP2&HF
8.3
18.8
22.0
21.06
cc-pVDZ Regular
76.7
2.9
267.8
3.52
CD/MP2
55.8
6.1
188.6
8.06
CD/MP2&HF
34.7
26.3
81.0
30.43
1C-CD/MP2
52.1
3.2
170.1
3.77
1C-CD/MP2&HF
16.6
14.9
39.1
18.86

6-31G*基底では良好な効率を出していることが見てとれます。また、1C 化で効率は低下しますがジョブ時間はさらに短くなっています。
続けて、実タンパク質として HIV-1 プロテアーゼを使った FMO2-MP2 計算の結果を下表に示します。残基数は 198、中心部に嵌るリガンドであるロピナビルを 4 分割、さらに水分子を含めた総数で 203 フラグメントの系を 204 ノードで計算しました。
実行効率は、
やはり CD で HF と MP2を共に処理すると高くなり、計算時間はほぼ半分となります。通常積分での 6-31G のコストと
1C-CD での 6-31G*のコストがほぼ同じであり、d分極関数を含み信頼性に勝る 6-31G*の利用が容易になっています(最近の FMO 応用計算では6-31G*が標準基底です)。一方で、cc-pVDZ は原Basis set TEI treatment
Time (Min) Eff. (%)
HIV-1 Protease + Lopinavir (204 frag.) @ 204 nodes
6-31G
Regular31.9
1.85
CD/MP2&HF
18.8
7.78
1C-CD/MP2&HF
14.8
3.74
6-31G*
Regular74.5
2.67
CD/MP2&HF
44.0
17.54
1C-CD/MP2&HF
29.4
8.30
cc-pVDZ Regular
161.3
2.69
CD/MP2&HF
80.4
17.47
1C-CD/MP2&HF
58.3
8.02

始関数の多さから 6-31G*に比べても相対的に時間がかかっています。
FMO4-MP2 ジョブでは、組合わせ的に多くなるテトラマーの処理、特に繰り返し計算を伴う
HF ステップが占めてしまいます。メモリ要求の関係からテストでは 6-31G 基底とし、43 残基の235 / 253

クランビンと HIV-1 プロテアーゼ(共に主鎖と側鎖を分割で総数で各々94、363 フラグメント)でタ
イミングデータを取りました。右表より、通常 2電子積分に比べて CD では約 1/3 の時間で計算出来ることが分かります。
FMO4 計算でノード数使用最多の例は、インフルエンザウィルスのノイラミニダーゼ(386 残基)

Basis set TEI treatment
Time (Min) Eff. (%)
Crambin (94 frag.) @ 960 nodes
6-31G
Regular23.7
2.06
CD/MP2&HF
9.1
12.06
1C-CD/MP2&HF
6.7
6.38
HIV-1 Protease + Lopinavir (363 frag.) @ 6000 nodes
6-31G
Regular144.3
2.79
CD/MP2&HF
128.0
11.85
1C-CD/MP2&HF
49.5
6.88

とタミフルの複合系(総数では 706 フラグメント)の FMO4-MP2/6-31G(HF と MP2 を共に 1C-CDで計算)の 12504 ノードでのテストジョブで、計算自体は 1.1 時間で完走しています(計算結果のファイルリスティングまで含めると 1.5 時間)[4]。計算時間全体での効率は 6%ですが、全体の半分以上のコストが SCC 条件を課すフラグメントモノマーの HF ステップとなってしまっています。
FMO4 では、このあたりに抜本的な改善を図る必要がありそうです。
【FX-10 と FX-100 での結果】

RIST 神戸の FX-10 は、共同研究により 2014 年度から利用させていただいています。2014 年 12 月の SS 研の第一回の報告時には前述のコンパイラの問題があり、d 関数積分ルーチンを Opt2 としてコンパイルしたものでジョブタイミングを紹介し、PAによる解析で 2 電子積分の CD 化によって DGEMM 処理比率が大きく改善されることをお示ししました(通常積分で 10%が CD で 74%、1C-CD で 63%)。コンパイラの件は、その後すぐ富士通さんにご対応をいただき、"Technical Computing Suite V1.0L30"以降のコンパイラ環境では正常
オブジェクトが生成されることが確認されましたので、2015 年からはデフォールトの kfast オプ
ションでコンパイルしています。幸い、幾つかの系でテストしたところ、6-31G*を使う場合でもジョブの計算時間短縮は数%しか変わりませんでした(d 関数が 1 項展開で相対コストが小さいため)。そこで、FX-10 のデータは基本的に第一回報告のままとしました(ノード内は 16 スレッドのOpenMP 並列とし、ノード数を増加させてスケーリングに注目)。JAXA の FX-100 でのタイミン
グ測定は、コードと入力データなど一式を高木亮治先生に委託して行っていただきました(2015年秋)。これ以下、注記しない限りは FMO2-MP2/6-31G*ジョブでの結果を示していきます(CD の場合は HF も MP2 も CD で実行)。また、”Conv”は通常 2 電子積分の使用を意味します。
最初に、10 残基の Chignolin、粒度を揃えた Trp9His の FX-10 での結果を下表にまとめます。
FX-10
Method#nodesConv-MP2
1
2
5
10
Full-CD
1
2
5
10
1C-CD
1
2
5
10

Monomer
2111.01076.7520.0
457.5
1390.1
710.1
501.3
500.1
568.6
294.9
177.8
176.9

Chignolim
Dimer
Total
5394.27505.22789.23865.91257.41777.5834.51292.01728.1
3118.2875.6
1585.7
394.1
895.5
230.5
730.6
762.9
1331.5
387.6
682.6
171.2
349.0
99.9
276.8

236 / 253

Acc Monomer
13835.7
1.94
1941.1
4.22
809.3
5.81
413.8
1
4164.31.97
2117.2
3.48
888.5
4.27
473.1
1
1635.4
1.95
832.5
3.82
347.0
4.81
184.4

Trp9HisDimer
Total
29524.3
33360.1
15101.3
17042.4
5905.16714.43297.43711.27943.612107.9
4051.36168.51619.02507.5890.51363.53398.05033.41730.52563.0695.5
1042.5
384.1
568.5

Acc
1
1.96
4.97
8.99
1
1.96
4.83
8.88
1
1.96
4.83
8.85

ノード数増に対する加速ですが、大小のアミノ酸残基を複数種含む Chignolin では 10 ノードでは完全にドロップしてしまっており、CD では 2 電子積分関係のコストが下がるために劣化が目立つ形になっています(特にモノマーの部分)。一方、ジョブ時間が 4 倍ほどかかることからも明らかなように、Trp9His では Trp が処理的に重く、かつ数が揃っているために良好なスケーリングを示しています。時間短縮としては、1C 化の効果が確かにあります。
続いて FX-100 での結果ですが、こちらはノード内で 16 スレッドで 2 プロセスまで立てられるので、ノードを跨ぐ場合/跨がない場合の 2 通りを試していますが、大きな差はありませんでした。
FX-100#nodes
Method(n-p-t)Conv-MP2 1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16
Full-CD
1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16
1C-CD
1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16

Trp9HisChignolim
Monomer
614.3
326.7
325.8
237.8
230.7
230.1
713.5
347.8
349.8
244.4
244.8
245.3
291.0
151.8
151.8
85.7
87.8
88.8

Dimer

Total

Acc

Monomer

Dimer

Total

Acc

3132.2
1622.71620.3
838.4
564.3
563.1
783.6
394.6
395.9
180.5
106.4
106.4
363.4
184.8
184.7
85.2
51.9
51.9

3746.6
1949.4
1946.1
1076.2795.0
793.2
1497.1
742.4
745.7
424.8
351.2
351.7
654.4
336.6
336.5
170.9
139.7
140.6

1
1.92
1.93
3.48
4.71
4.72
1
2.02
2.01
3.52
4.26
4.26
1
1.94
1.94
3.83
4.68
4.65

1924.2
976.1
977.5
403.7
208.2
208.5
2081.61058.81061.2
439.1
238.0
239.2
826.0
418.4
419.6
173.9
92.7
93.2

15887.8
8138.78215.33554.12077.52090.53593.6
1833.71831.5
740.6
407.2
407.9
1712.2
872.1
871.3
355.1
195.7
195.6

17811.99114.89192.83957.92285.62299.05675.22892.52892.71179.8645.2
647.1
2538.21290.51290.9
529.1
288.4
288.8

1
1.95
1.94
4.50
7.79
7.75
1
1.96
1.96
4.81
8.80
8.77
1
1.97
1.97
4.80
8.80
8.79

これは、FX-100 のネットワークの高速性の証左とも言えるでしょうか。FX-10 とのジョブ時間の比較では、約 2 倍速くなっていることが分かります。スケーリングの傾向は FX-10 と同様ですが、
CPU コアの速度が速い分、ノード数が多い場合は僅かですが低下が見られます。
次に、FX-100 による HIV-1 プロ
テアーゼのタイミングを右に示します。ノード内で 16 スレッドを 32 に倍化させてみたのですが、1.4 倍程
度の加速に留まりました。また、スレッドを 8 に半減してプロセス数を倍化したテストも行い、若干の加速を確認しました。こうした実タンパ
ク質の応用計算で、条件出しの試行

FX-100#nodes
Method(n-p-t)Conv-MP2 36-36-16
36-36-32
72-72-8
Full-CD
36-36-16
36-36-32
72-72-8
1C-CD
36-36-16
36-36-32
72-72-8

HIV-1 protease
Monomer
853.3
549.8
916.2
913.8
658.1
883.3
637.1
437.8
529.8

Dimer
5093.13571.44458.82613.31950.92072.82146.4
1622.81648.4

Total

Acc

5946.54121.25375.13527.12608.92956.12783.52060.62178.2

1
1.44
1.11
1
1.35
1.19
1
1.35
1.28

錯誤はあまり現実的ではありません
ので、ノード内を 8 ないし 16 スレッドとして、プロセス-ノード数を積んでいく方が実用的かと思われます。比較対象の FX-10 ですが、ノード内で 16 スレッド、総数で 36 ノードでのタイミン
グは、”Conv”、”Full-CD”、”1C-CD”の順に 9552.5 秒、4883.5 秒、3296.7 秒です。FX-100 では

237 / 253

CPU コアの速度が速い分、少ないノード数でも FX-10 よりも速くジョブを終わらせることが出来ますので、ノード資源を上手く分割して複数のサンプルを同時並行的に(capacity computing)
流す方が有利と考えられます。
最後に、2015 年の秋にアルゴリズムを改良して再実装した CD ベースの FMO2-MP3/6-31G*
計算の FX-10 でのベンチマーク結果を示します。MP3 ではメモリ要求が MP2 よりも大きくなる
ため、Ala9Gly を選びました。MP2 の結果も最新のコンパイラを使ってのバイナリでのものです。
FX-10
Integral#nodes
Conv
1
2
5
10
Full-CD
1
2
5
10
1C-CD
1
2
5
10

FMO2-MP2 - Ala9Gly
Monomer
Dimer
Total
815.4
982.1
1797.5
470.1
490.5
960.6
228.5
202.5
430.9
100.6
103.0
203.6
312.6
317.6
630.2
163.2
158.7
321.9
70.9
65.2
136.2
57.6
33.0
90.6
133.2
147.7
280.9
69.2
74.6
143.8
30.2
30.8
61.0
25.3
15.9
41.2

Acc
1
1.87
4.17
8.83
1
1.96
4.63
6.96
1
1.95
4.60
6.82

FMO2-MP3 - Ala9Gly
Monomer
Dimer
Total
852.1
3024.43876.5487.8
1524.92012.7
235.7
648.7
884.4
111.7
427.5
539.2
379.0
6604.1
6983.0202.7
3388.53591.293.21480.71573.9
80.2
875.7
955.9
163.6
3107.23270.787.3
1602.31689.6
41.0
697.5
738.5
35.7
420.3
456.0

Acc
1
1.93
4.38
7.19
1
1.94
4.44
7.31
1
1.94
4.43
7.17

比較のために通常 2 電子積分での計算も行いましたが、MP3 エンジン[11]が DGEMM を多用しつつ、無駄な演算を巧妙に省くように高度に最適化されているため、1C 化してない Full CD ではむしろ計算時間が増えてしまっており、1C でも時間短縮の効果は僅かです。主な理由は、CDでは既述のように分解基底を基底関数自身の積とするので Full の場合、そこで自乗の依存性が伴ってしまい、MP3 ではテンソル積和のオーダーが MP2 よりも本質的に 2 だけ多いこともあり、演算数が実効的に増加して DGEMM 処理による加速でもカバーし切れないためと考えられます。
1C 制限では分解基底の数が減りますのでコストは下がりますが、CD の代わりに RI[10]を導入す
ることがより根本的な改善策になると思われます。スケーリングについては、このテスト系では
MP3 と MP2 は同程度のようですが、今後は他の系でもテストをしてみたいところです。
【ABINIT-MP の今後】

ABINIT-MP には、東大の生産研サイト[5]からバイナリでダウンロー

ド可能な版とは別に、主に開発経緯的な事由から「ローカル版」が存在しています[4]。そちらでは、励起エネルギー[14]や動的分極率の算定[15]、さらに結合クラスター展開による高精度エネル
ギー計算[16]などが利用出来ます。こうした機能に関心を持たれる方も居られますし、手持ちのマシン環境によっては再コンパイルやチューニングのためにソースを所望される場合もあります。
現在、産官学を交えたコンソーシアム的な組織で ABINIT-MP のソース共有を行い、創薬系だ
けでなくものづくり分野への本格的な対応など、継続的なコード開発と保守を図っていくための準備を進めています。これに併せて、版管理も Open シリーズに移行します。Ver.7 に準拠した最初の Open Ver.1 については、2015 年度内のリリースを目指しています。また、2016 年度に整備する Open Ver.2 では、密度汎関数(DFT)のモジュールを分子研の石村和也氏の SMASH[17]から、また上記で懸案の RI 関係のモジュール(C 言語で記述)を PAICS[6]から移植する他、「ローカル版」

238 / 253

の幾つかの機能を含める予定です。また、ホットスポットの洗い直しやメモリ割り当ての見直しなども行い、パフォーマンスの総合的な向上も図ります。Open Ver.3 以降も機能充実を順次進めていきます。
ソース共有とは別に Open シリーズでも従来のバイナリでの提供も続けるつもりですが、これまでの Intel Xeon 系と富士通系だけでなく、NEC のベクトル系、さらにパソコン用に Windows
64 ビット系を提供しようと考えています。なお、ソース共有コンソーシアムのポータルサイトは「計算工学ナビ」[18]を予定しています。
Open シリーズのベンチマークは、2016 年度も引き続いて RIST の FX-10 を使って行っていきますが、FX-100 もチャンスがあれば是非利用したいところです。他方、GAMESS では Xeon Phi(KNC)[19]や ARM-32/-64[20]での試行が既に報告されています。小研究室でも SMASH を使った
Phi でのテストを始めており、2016 年度は ABINIT-MP でも行うことになっています。Phi や
ARM などの省エネルギーに優れる加速器的な技術は今後は重要性が増す可能性も高く、継続してウォッチしていく必要を感じているところです。
【謝辞】

ABINIT-MP の研究開発は、様々な資金援助を頂戴してここまで続けてくることが出来ました。本稿に記載した内容に関連しては、文科省の「HPCI 戦略プログラム 分野 4」(代表者：
東大 加藤千幸教授)と「フラッグシップ 2020 プロジェクト 課題６」(代表者：東大 吉村忍教授)から支援を受けています。後者はポスト「京」に関する研究活動で、ものづくり文脈を明確にしつつ ABINIT-MP - Open シリーズの改良・機能拡張が 2019 年度まで継続されていく予定です。
個人としましては、SS 研の本 WG への参加をお誘いくださいました JAXA の高木亮治先生に先ず感謝したいと思います。「京」での実行は、沖山佳生氏と渡邉千鶴氏(共に元東大：現理研)に依ります。FX-10 でのベンチマークは、RIST 神戸の山木大輔、野口孝明、小久保達信、吉澤香
奈子の諸氏のご支援の下、小研究室の齊藤天菜君と坂口正貴君が行ってくれました。また、
ABINIT-MP のコアメンバである神戸大の田中成典先生、日大の福澤薫先生、NEC の坂倉耕太氏にも謝意を表します。
【文献】[1] M. S. Gordon et al., Chem. Rev. 112 (2012) 632. [2] "The Fragment MolecularOrbital Method: Practical Applications to Large Molecular Systems", (2009, CRC). [3] D. G.
Fedorov et al., Phys. Chem. Chem. Phys. 14 (2012) 7562. [4] S. Tanaka, et al., Phys. Chem.

Chem. Phys. 16 (2014) 10310. [5] <http://www.ciss.iis.u-tokyo.ac.jp/software/>. [6] T. Ishikawa
et al. J. Comp. Chem. 30 (2009) 2594. [7] T. Nakano et al., Chem. Phys. Lett. 523 (2012) 128.
[8] 「京算百景」, Vol. 9, 2014 年 3 月 10 日. [9] Y. Okiyama et al., Chem. Phys. Lett. 490 (2010)
84. [10] T. B. Pedersen, Theor. Chem. Acc. 124 (2009) 1. [11] Y. Mochizuki et al., Chem. Phys.

Lett. 493 (2010) 346. [12] T. Tsukamoto et al., Chem. Phys. Lett. 535 (2012) 157. [13] Y.
Komeiji et al., Intech J. <http://bit.ly/HkefpI>. [14] Y. Mochizuki et al., Theor. Chem. Acc. 117(2007) 541. [15] Y. Mochizuki et al., Chem. Phys. Lett. 418 (2006) 418. [16] Y. Mochizuki et al.,Theor. Chem. Acc. 130 (2011) 515. [17] K. Ishimura, < http://smash-qc.sourceforge.net/>. [18]<http://www.cenav.org/>. [19] V. Mironov et al., ISC High Performance 2015, LNCS 9137
(2015) 113. [20] K. Keipert et al., J. Chem. Theor. Comp. 11 (2015) 5055.

239 / 253

2016/2/5 SS研 – 最終提出資料

FMOプログラムABINIT-MPの富士通系マシンでの性能評価
立教大学

望月祐志*、齊藤天菜、坂口正貴
NEC
坂倉耕太
RIST神戸
山木大輔、野口孝明、小久保達信、吉澤香奈子（元）東京大学生産技術研究所
沖山佳生、渡邉千鶴
日本大学
福澤薫
神戸大学
田中成典

文科省系プロジェクト サポート： HPCI 戦略分野４ / FS2020 重点課題６
FX-100 @ JAXAでのベンチマークを実施

FMO Original; Kiitaura et al., Chem. Phys Lett. 313 (1999) 701 / General Ref.; Gordon et al., Chem. Rev. 112 (2012) 632.

フラグメント分子軌道（FMO）法◇巨大分子系
生体高分子や凝集系では一般的⇒ タンパク質、DNA （水和状態）
数千～数万原子、数千～数十万軌道【HIVプロテアーゼとロピナビル】◇分割&統合系のアプローチの一つ
北浦らが15年程前に2体展開で提案⇒ フラグメントとその対で系のエネルギーを評価 （FMO2）⇒ 環境静電ポテンシャル （ESP）、直接結合切断 （BDA）⇒ 階層的な並列処理 （フラグメントリスト&内部処理）⇒ 電子相関の導入、構造最適化も可能
フラグメント間の相互作用エネルギー （IFIE） E  E  ( N  2) E
⇒ 計算対象の解析ツール⇒ 創薬設計には好適E   E   E '⇒ ナノ系の問題でも利活用可能
I J

I J

IJ

f

I

I

IJ

I

I

2

平成28年3月1日

240 / 253

Ref.; Nakano et al., Chem. Phys. Lett. 318 (2000) 684. & Nakano et al., Chem. Phys. Lett. 351 (2002) 475.

基本のHF計算F x C x  S x C xε x

⇔ HFの一般化固有値問題 （要反復計算）

Fx  H x Gxxcore xH 
 H 
 Vx   Bk   k  k KKVx   u 
 v

K
u
    Z A r  A  Kv
  PK   

K x

k

 K

AK

⇔ 1電子部分の修飾⇔ 環境静電ポテンシャル（ESP)1x  Px         
G
2


 x

occ

P  2 C* iC i
i 1⇔ 2電子部分 （N4）
（並列処理）

高速化のための幾つかの工夫
VL   (P LS L )  (  ,  )for Rmin ( X , L)  Laoc

⇔ ESP-AOC近似 （実用精度高し）

VL    QA r  A  

for Rmin ( X , L)  L ptc

QA   (P L S L )  ⇔ ESP-PTC近似 （速い）

L

AL





 A





I
J
E ' IJ  E ' I  E ' J  Tr P I u J  Tr P J u I    P
P(  ,  ) I  J⇔ Dimer-ES近似 （HF計算無）種々の工夫により、FMO2の計算コストのシステムサイズ依存性は2乗より低い
3

2016/3/1

Ref.; Szabo & Ostlund, “Modern Quantum Chemistry”.

2次と3次の摂動による電子相関エネルギーの式
2次摂動(MP2) による相関： 占有軌道iとjの電子対が“衝突”して仮想軌道aとbに“散乱”
a

b

⇔
i

⇔

E MP 2 ( 2 p2 h ) jij || ab ab || ij
1
4 ijab  i   j   a   b（分母は電子間の反発積分、分子は軌道エネルギーの差）（電子対の相互作用）

3次摂動(MP3) による相関： 電子対間の相互作用も3通りで追加的に考慮して補正⇔
相関エネルギーの計算はHF計算
完了後続けて行う （寄与を加算）

E MP 3( 4 p2 h ) ij || ab ab || cd cd || ij
1

8 ijabcd ( i   j   a   b )( i   j   c   d )E MP 3( 2 p4 h ) ij || ab ab || kl kl || ij1

8 ijklab ( i   j   a   b )( k   l   a   b )ij || ab kb || cj ac || ik
ijkabc ( i   j   a   b )( i   k   a   c )E MP 3(3 p3h )  

4

2016/3/1

241 / 253

Refs.; Mochizuki et al., Chem. Phys. Lett. 493 (2010) 396. & Mochizuki et al., Theor. Chem. Acc. 130 (2011) 515.

MPI/OpenMP混成並列化
フラグメント間をMPI、フラグメント内をOpenMPで並列化⇒ 混成並列化
Target system

Fragment momer(or dimer)

Parallelized by fragment
indices

MPI並列→
OpenMP並列→
Parallelized by integral
indicesProcessor group

作業配列をスレッド間で共有してメモリを節約⇒ ABINIT-MPではES2用に開発、メモリの少ない京では必然
従来の並列化(MPI)
CPU0 CPU1 CPU2 CPU3

SMP並列化(OpenMP)
メモリ

メモリ

CPU0 CPU1 CPU2 CPU3

MPI通信

5

2016/3/1

Recent ABINIT-MP Ref.; Tanaka et al., Chem. Phys. Phys. Chem. 16 (2014) 10310.

ABINIT-MPの主な機能 (2015年夏の段階)
E FMO4 E

 ( N  4)  EIJK ( N  3)( N  4)
 EIJ
2
I J

・エネルギー( N  2)( N  3)( N  4)
E
6
→ FMO4： HF, MP2  E  E  E  E  E  E  E
→ FMO2： HF, MP2～CCSD(T)  E  E  E  E   E  E  E  E  E  E  E  E  E  E  E  E → FMO2： CIS, CIS(D)系
  E  E  E  E ・エネルギー微分  E   E→ FMO4： HF, MP2【ABINIT-MP独自の4体フラグメント展開 (FMO4)】→ FMO2： MP2構造最適化, MD Ref.; Nakano et al., Chem. Phys. Lett. 523 (2012) 128.
・その他機能→ SCIFIE, PB, CAFI, FILM
→ 可視化（BioStationViewer）
・並列化環境（小型サーバ~スパコン）→ MPI, OpenMP/MPI混成→ 最深部はBLAS処理【BioStationViewer / GUI】
6IJKLI J K L

I J K

I

I

I J K L

IJKL

IJK

IJ

IKL

平成28年3月1日

242 / 253

IK

I

I

IL

JK

IL

IJ

IJ

IK

IK

IJK

I J K

I J

IJ

KL

IK

JK

JL

KL

IJL

IJ

IL

JL

JKL

JK

JL

KL

JK

（IFIEのΔEではなくエネルギー差そのものです）

1st. Refs.; Mochizuki et al., Chem. Phys. Lett. 396 (2004) 473. & Mochizuki et al., Theor. Chem. Acc. 112 ( 2004) 442.
2nd Ref.; Mochizuki et al., Chem. Phys. Lett. 457 (2008) 396.

MP2計算の基本アルゴリズム2種： 形式的にN5スピンを積分した実装式
Loop over i-batch [parallelizable when needed]
Loop over s [to be parallelized for worker processes]
Loop over r
Generate (pq,r[s]) list [canonical relation for pq]
Do 1/4 transformation of p→i [screening & DAXPY]Do 2/4 transformation of q→a [DDOT]
Do 3/4 transformation of r→j [screening & DAXPY]End of loop over r
Do 4/4 transformation for s→b [screening & DAXPY]End of loop over s [“all-reduce” must be done for (ia,jb)]Calculate partial MP2 energy
End of loop over i-batch(ia, jb)2(ia, jb)  (ib, ja )
i   j  a  b
ijab

EMP2  

添字の変換： 4N5コスト




(ia, jb)   csb   crj   C qa   c pi ( pq, rs )   
 q

 r
s
 p
  


【第一版】
・ DAXPYとDDOTを使い、閾値判断を優先・ 実効的演算数を下げる方針、
10年前のチップでは有効

Loop over ij-batch ! size depending on available memory
Loop over s ! to be parallelized
Loop over r
Preparing (pq,rs) ! for canonical pq-pair
Forming (iq,rs) ! DGEMM, fixed rs, running over p
Forming (ia,rs) ! DGEMM, fixed rs, running over q
Forming (ia,js) ! DGEMM, fixed s, direct-product for fixed r
End of loop over r
Forming (ia,jb) ! DGEMM, direct-product for fixed s
End of loop over s ! all-reduce operation as barrier
Calculate partial MP2 energy with respect to ij-batch
End of loop over ij-batch【第二版】
・ DGEMMの高性能に期待【現在：混成型】
・ スカラ型のCPUでもステップ2とステップ4はDGEMMで
7

2016/3/1

Ref.; Okiyama et al., Chem. Phys. Lett. 490 (2010) 84. / general CD Ref.; Pedersen et al., Theor. Chem. Acc. 124 (2009) 1.

コレスキー分解（CD)による近似： テンソル次数の低減
MP2 correlation energy ( MP2 )Loop over I # Parallelized

Coulomb matrix (J)0Loop over I # Parallelized# DDOT,,# DGEMM,,# DGEMMEnd of loop over I# DAXPY,,,
Exchange matrix (K),End of loop over I
ALLREDUCE
2016/3/1

MP2# DGEMM,,

ALLREDUCE

0
Loop over I # Parallelized
,

MP2

0
Loop over ij # Canonical ij pairEnd of loop over I
ALLREDUCE

,

MP2

,

# DGEMM partial sum of I

,
2

2

,

,

,

End of loop over ij( pq, rs )   LI , pq LI ,rs# DGEMMI・ CDでは分解基底は軌道積に取る： 展開長MはN2オーダー
・ CD 1中心(1C)化は同一原子内に限る： MはNに近い・ RI近似では最適化基底を別途調製： 展開長はほぼN
243 / 253

8

ABINIT-MPはVer.6準拠 / Regularが通常の2電子積分を使うアルゴリズム

小型タンパク質での「京」での性能評価の例
NLYIQWLKDGGPSSGRPPPS
FMO2-MP2ジョブ @ 24ノード
Basis set

Time (Min) Eff. (%) Time (Min) Eff. (%)
TrpCage (20 frag.)
Trp23His
6-31G
Regular
12.6
2.3
36.8
2.53
CD/MP2
8.2
4.4
19.5
7.13
CD/MP2&HF
5.7
15.6
14.6
18.35
1C-CD/MP2
7.6
2.5
16.7
2.97
1C-CD/MP2&HF
3.0
8.8
8.2
9.66
6-31G*
Regular
38.2
3.0
136.9
3.43
CD/MP2
28.0
6.6
96.0
8.87
CD/MP2&HF
18.9
29.0
44.6
31.89
1C-CD/MP2
25.9
3.4
84.7
3.88
1C-CD/MP2&HF
8.3
18.8
22.0
21.06
cc-pVDZ Regular
76.7
2.9
267.8
3.52
CD/MP2
55.8
6.1
188.6
8.06
CD/MP2&HF
34.7
26.3
81.0
30.43
1C-CD/MP2
52.1
3.2
170.1
3.77
1C-CD/MP2&HF
16.6
14.9
39.1
18.86

2016/3/1

TEI treatment【TrpCage】

,

,

,

,

・ CDではHF計算の交換項(K)をDGEMMで処理
・ モデル系では最高で30%を超える効率を達成
・ トータルでの時間短縮は1Cでは最高6倍程度

9Regularの速さは「実効演算数」の少なさも効いている

実タンパク質での「京」での性能評価の例
FMO4-MP2ジョブ
FMO2-MP2ジョブ
Basis set TEI treatment
Time (Min) Eff. (%)
HIV-1 Protease + Lopinavir (204 frag.) @ 204 nodes
6-31G
Regular31.9
1.85
CD/MP2&HF
18.8
7.78
1C-CD/MP2&HF
14.8
3.74
6-31G*
Regular74.5
2.67
CD/MP2&HF
44.0
17.54
1C-CD/MP2&HF
29.4
8.30
cc-pVDZ Regular
161.3
2.69
CD/MP2&HF
80.4
17.47
1C-CD/MP2&HF
58.3
8.02
Infulenza HA1 + Fab (911 frag.) @ 912 nodes
6-31G
Regular
123.2
1.01
CD/MP2&HF
110.7
2.27
1C-CD/MP2&HF
106.1
1.14
6-31G*
Regular212.1
1.62
CD/MP2&HF
166.5
6.47
1C-CD/MP2&HF
146.5
2.66
cc-pVDZ Regular
400.5
2.32
CD/MP2&HF
296.6
8.14
1C-CD/MP2&HF
269.9
3.37

Basis set TEI treatment
Time (Min) Eff. (%)
Crambin (94 frag.) @ 960 nodes
6-31G
Regular23.7
2.06
CD/MP2&HF
9.1
12.06
1C-CD/MP2&HF
6.7
6.38
HIV-1 Protease + Lopinavir (363 frag.) @ 6000 nodes
6-31G
Regular144.3
2.79
CD/MP2&HF
128.0
11.85
1C-CD/MP2&HF
49.5
6.88

 FMO2計算→ 数百残基の計算は容易→ 6-31G*基底の実用利用→ 実行効率は及第レベル→ 1中心CDAMで時間短縮（実用性には問題無し）
 FMO4計算→ 多ノード利用のメリット→ 1中心化の効果は顕著→ 詳細解析の用途を推奨→ HFのコスト低減は課題

2016/3/1

244 / 253

【インフルHA+Fab】

10

「京」での1.2万ノード計算の例
−
−
−
−

O-

インフルエンザノイラミニダーゼ（386残基）
FMO4-MP2/6-31G（1C-CDAM）
フラグメント数 706（主鎖/側鎖分割、リガンド分割）
OpenMP版 THREADS=8 ・Kfast+部分的O2指定(*OpenMP版 THREADS=8 ・Kfast指定)
20000

5.4時間*

18000

H3N+

O
NH
O

1.5時間
Tetramer MP2

16000

Trimer MP2

14000
Time (sec)O

Dimer MP2

12000

Monomer MP2

73%減

10000

Tetramer SCF

8000

Trimer SCF

6000

Dimer SCF

4000

Dimer ES

2000

Monomer SCF

0706 nodes *2016/3/1

12504 nodes

効率は6% @ 100032コア
11（計算時間は各々5.0時間と1.1時間）

FX-10、-100共に最新のコンパイラ環境でkfastでビルド（d積分ルーチン問題は解消済）

FMO2-MP2タイミング #1 chignolin (10残基)
FX-10 @ RIST
OLD
Chignolin(10 res)

MethodNumber of Proc

点線

Conv-MP212
510Elapsed time [second]
Monomer SCF
Monomer MP2
1958.7
143.0
994.6
77.0
471.1
46.4
408.8
46.0

実線

Full-CD(HF & MP2)

1
2
5
10

1342.3
685.1
483.7
482.5

破線

1C-CD
(HF & MP2)

1
2
5
10

547.8
284.1
171.0
170.1

Monomer (Total)
2111.01076.7520.0
457.5

Dimer ES
10.2
6.4
5.6
5.5

Dimer SCF
1643.1
777.9
424.0
286.3

Dimer MP23608.91942.4802.3
535.3

Dimer (Total)
5394.22789.21257.4834.5

FMO (Total)
7505.23865.91777.51292.0

38.4
19.9
15.0
14.9

1390.1
710.1
501.3
500.1

10.2
6.4
5.6
5.5

1282.3
639.0
287.1
161.4

435.3
230.0
101.5
63.6

1728.1
875.6
394.1
230.5

3118.21585.7
895.5
730.6

11.5
5.7
4.2
4.2

568.6
294.9
177.8
176.9

10.2
6.4
5.6
5.4

539.7
268.7
116.6
63.6

212.6
112.2
49.0
30.8

762.9
387.6
171.2
99.9

1331.5
682.6
349.0
276.8

FX-10に比して約2倍の加速
ノード跨ぎの性能低下は少ない

FX-100 @ JAXA
FX100
Chignolin(10 res)

点線(n-p-t)=(node-process-thread)
MethodNumber of Proc(n-p-t)Conv-MP2
1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16

Elapsed time [second]
Monomer SCF
Monomer MP2
543.1
64.5
287.6
35.1
286.7
35.2
208.2
27.8
201.2
27.6
200.6
27.6

Monomer (Total)
614.3
326.7
325.8
237.8
230.7
230.1

Dimer ES
14.1
9.5
9.3
8.4
8.5
8.5

Dimer SCF
1194.9
602.7
601.7
360.1
262.0
261.5

Dimer MP2
1922.21010.41009.2
469.8
293.7
293.0

Dimer (Total)
3132.2
1622.71620.3
838.4
564.3
563.1

FMO (Total)
3746.6
1949.4
1946.1
1076.2
795.0
793.2

実線

Full-CD(HF & MP2)

1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16

687.6
334.8
336.7
235.5
236.0
236.5

18.8
9.5
9.6
7.0
7.0
7.0

713.5
347.8
349.8
244.4
244.8
245.3

14.1
9.4
9.3
8.5
8.5
8.5

601.3
297.9
299.1
133.0
74.1
74.0

168.2
87.3
87.4
38.8
23.9
23.8

783.6
394.6
395.9
180.5
106.4
106.4

1497.1
742.4
745.7
424.8
351.2
351.7

破線

1C-CD
(HF & MP2)

1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16

279.2
145.5
145.5
82.0
84.2
85.1

5.3
2.7
2.7
1.9
1.9
1.9

291.0
151.8
151.8
85.7
87.8
88.8

14.2
9.5
9.3
8.5
8.5
8.5

263.6
130.5
130.8
57.0
31.3
31.3

85.7
44.7
44.7
19.7
12.1
12.1

363.4
184.8
184.7
85.2
51.9
51.9

654.4
336.6
336.5
170.9
139.7
140.6

12

2016/3/1

245 / 253

FMO2-MP2タイミング #1 chignolin (10残基)
Gly1-Tyr2-Asp3-Pro4-Glu5-Thr6-Gly7-Thr8-Trp9-Gly10

13

2016/3/1

FX-100のグラフはノード数＝プロセス数のものをプロット（スレッドは16）

FMO2-MP2タイミング #1 chignolin (10残基)
FX-10比で約2倍の速さ

14

2016/3/1

246 / 253

FMO2-MP2タイミング #2 Trp9His (10残基)
FX-10 @ RIST
OLD
Trp9His(10 res)

MethodNumber of Proc

点線

Conv-MP212
510Elapsed time [second]
Monomer SCF
Monomer MP2
3389.6410.8
1713.1
210.2
715.6
86.1
366.5
43.4

実線

Full-CD(HF & MP2)

1
2
5
10

3994.62030.6
852.1
454.0

破線

1C-CD
(HF & MP2)

1
2
5
10

1561.9
794.9
331.3
176.4

Monomer (Total)
3835.7
1941.1
809.3
413.8

Dimer ES
104.5
53.3
22.5
12.4

Dimer SCF
7950.53643.31708.7696.7

Dimer MP221336.910288.04147.5
1895.2

Dimer (Total)
29524.3
15101.3
5905.13297.4

FMO (Total)
33360.1
17042.4
6714.43711.2

134.4
68.7
28.8
14.9

4164.32117.2
888.5
473.1

104.5
52.9
22.4
12.7

5483.02677.31133.1507.22355.91158.2463.5
211.5

7943.64051.31619.0890.512107.96168.52507.51363.5

38.2
19.7
8.1
4.0

1635.4
832.5
347.0
184.4

104.5
53.2
22.5
12.6

2189.21068.3454.6
202.9

1104.2
543.7
218.4
100.5

3398.01730.5695.5
384.1

5033.42563.01042.5568.5

Trp9Hisはモデル系で計算は重め
加速はchignolinより若干向上

FX-100 @ JAXA
FX100
Trp9His(10 res)

点線(n-p-t)=(node-process-thread)
MethodNumber of Proc(n-p-t)Conv-MP2
1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16

Elapsed time [second]
Monomer SCF
Monomer MP21655.4
243.8
839.1
124.4
838.6
125.2
347.1
51.2
179.6
25.8
179.8
25.8

Monomer (Total)
1924.2
976.1
977.5
403.7
208.2
208.5

Dimer ES
173.2
87.0
87.2
39.1
21.5
21.5

Dimer SCF
6634.13186.83184.51553.9640.4
640.1

Dimer MP29080.34364.24401.3
1961.1825.9
802.5

Dimer (Total)
15887.8
8138.78215.33554.12077.52090.5

FMO (Total)
17811.99114.89192.83957.92285.62299.0実線

Full-CD(HF & MP2)

1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16

1992.21013.21015.6
420.4
228.0
228.7

64.1
32.8
32.9
13.5
7.2
7.2

2081.61058.81061.2
439.1
238.0
239.2

172.5
86.9
87.0
38.8
21.5
21.7

2503.41222.41224.1
519.0
230.9
230.9

917.5
450.4
450.4
182.8
82.6
82.7

3593.6
1833.71831.5
740.6
407.2
407.9

5675.22892.52892.71179.8
645.2
647.1

破線

1C-CD
(HF & MP2)

1-1-16
1-2-162-2-16
5-5-16
5-10-16
10-10-16

783.7
396.7
398.0
165.0
88.2
88.4

17.3
8.9
8.9
3.7
1.8
1.9

826.0
418.4
419.6
173.9
92.7
93.2

172.5
87.2
87.0
39.1
21.4
21.5

1069.4
521.7
521.6
222.7
99.0
99.1

470.3
229.7
229.6
93.3
42.3
42.3

1712.2
872.1
871.3
355.1
195.7
195.6

2538.21290.51290.9
529.1
288.4
288.8

15

2016/3/1

FMO2-MP2タイミング #2 Trp9His (10残基)
ベンチ用に粒度を揃えた効果が見える16

2016/3/1

247 / 253

FMO2-MP2タイミング #2 Trp9His (10残基)
FX-10比で約2倍の速さ

17

2016/3/1

1ノード、16スレッドの条件で実行

Trp9His のPAでの解析（FX-10） - 通常2電子積分*************************************************************************************
Process
0 - performance monitors*************************************************************************************
Elapsed(s)MFLOPS MFLOPS/PEAK(%)
MIPSMIPS/PEAK(%)-----------------------------------------------------------------------32768.6626
7527.0432
3.563924434.6821
23.1389-----------------------------------------------------------------------32768.6626
465.5478
3.52691451.3261
21.9898
32768.3581
498.2169
3.7744
1781.9925
26.999932768.3581
475.7742
3.60441696.1898
25.6998
32768.3581
462.5215
3.50401537.1240
23.2898
32768.3581
460.4899
3.4886
1553.7291
23.541332768.3581
482.4262
3.65471543.6502
23.388632768.3581
458.8652
3.47631532.2277
23.215632768.3581
457.2214
3.46381527.3619
23.141832768.3581
467.7318
3.54341524.9341
23.105132768.3581
460.0703
3.48541515.9977
22.969732768.3581
468.2977
3.54771509.0344
22.864232768.3581
482.9977
3.65911493.0931
22.6226
32768.3581
477.7212
3.61911471.0861
22.289232768.3581
476.3939
3.60901468.9008
22.256132768.3581
469.9461
3.56021434.1813
21.7300
32768.3581
462.8869
3.50671394.0669
21.1222

Process0

ThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThread

0
13
15
2
10
6
4
8
9
3
7
5
11
12
1
14

*************************************************************************************
Application - procedures*************************************************************************************
Cost% Operation (S)Barrier%StartEnd------------------------------------------------------------------------------------32714564 100.0000
327210.6875
10514044
32.1387--------------------------------------------------------------------------------------10733725
32.8102107358.5938
9787448
91.1841453
638
3413289
10.4335
34139.6758
60.000267375
3348662
10.2360
33493.2773
2848
0.08501
122356285
7.202623567.5352
26183
1.11121
25014432134.411514435.0000
00.00001
21310921173.338310923.3418
60752655.6283338
822
5321481.62665322.5381
00.000016
77495632
1.51504957.3057
00.00001693380148
1.16203802.2361
00.00001692364106
1.11303641.7839
00.000016
90Application
dmp2_ene_ij._OMP_1_
direct_scf_gmat._OMP_1_
dgemx_
get_tei_pq_fix_
get_tei_rs_fix_
dmp2_ene_ij_
sub_ssss_
sub_spss_
sub_sssp_
sub_ssps_

DgemxはwrapしたDGEMMで
10.2%

18

2016/3/1

248 / 253

Trp9His のPAでの解析（FX-10） - Full CD*************************************************************************************
Process
0 - performance monitors*************************************************************************************
Elapsed(s)MFLOPS MFLOPS/PEAK(%)
MIPSMIPS/PEAK(%)-----------------------------------------------------------------------12423.5145
63398.9059
30.018432088.5892
30.3869-----------------------------------------------------------------------12423.5145
4053.8133
30.71072194.8465
33.255212423.4433
3970.5250
30.0797
2007.2082
30.412212423.4433
3943.1042
29.8720
1994.2075
30.215312423.4433
3943.8243
29.8775
1993.6070
30.206212423.4433
3975.1896
30.1151
1997.4153
30.2639
12423.4433
3968.2847
30.0628
2004.1674
30.366212423.4433
3979.6754
30.1491
2002.3862
30.3392
12423.4433
3938.1847
29.8347
1986.7419
30.102212423.4433
3937.4160
29.8289
1986.0516
30.091712423.4433
3972.8625
30.0974
1994.5367
30.220312423.4433
3938.3377
29.8359
1986.1901
30.0938
12423.4433
3975.9605
30.1209
1995.8162
30.239612423.4433
3939.2306
29.8427
1984.7733
30.0723
12423.4433
3949.8235
29.9229
1982.9750
30.045112423.4433
3936.7083
29.8235
1983.3389
30.0506
12423.4433
3976.3059
30.1235
1994.4987
30.2197

Process0

ThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThread

0
6
11
9
4
7
2
15
14
5
13
3
10
8
12
1

*************************************************************************************
Application - procedures*************************************************************************************
Cost% Operation (S)Barrier%StartEnd------------------------------------------------------------------------------------15642706 100.0000
156648.0000
95132
0.6082--------------------------------------------------------------------------------------11624815
74.3146116412.3359
13524
0.11631128574215.48138586.3203
27325
3.1869861963623732.31663628.8481
00.000095
247
2022631.29302025.4867
00.00001
2031335700.85391337.5865
00.000016
771276940.81631278.7435
00.000016
93
1098600.70231100.1516
00.000016
9381559
0.5214816.741900.000016
11568158
0.4357682.5427
00.00001
6158923
0.3767590.0623
00.0000119
304

Application
dgemx_
direct_scf_gmat_cd._OMP_1_
coulomb_metric._OMP_1_
get_tei_pq_fix_cd_
sub_ssss_
sub_spss_
sub_psss_
sub_ppss_
fmt_
monomer_esp_electron_direct._OMP_1_

DGEMMは74.3% と
大きく上昇
↓
性能向上

19

2016/3/1

Trp9His のPAでの解析（FX-10） - 1C CD*************************************************************************************
Process
0 - performance monitors*************************************************************************************
Elapsed(s)MFLOPS MFLOPS/PEAK(%)
MIPSMIPS/PEAK(%)-----------------------------------------------------------------------5191.0808
48008.0999
22.731126812.1375
25.3903-----------------------------------------------------------------------5191.0808
3185.3280
24.13131977.6491
29.96445191.0054
3019.4644
22.8747
1674.3123
25.36845191.0054
3004.6186
22.76231672.0772
25.33455191.0054
2973.7315
22.52831657.3430
25.11135191.0054
2972.3038
22.5175
1652.5802
25.0391
5191.0054
2997.8868
22.71131662.7503
25.1932
5191.0054
3009.6369
22.8003
1662.7523
25.1932
5191.0054
2969.3276
22.4949
1651.0246
25.0155
5191.0054
2970.0616
22.5005
1646.8130
24.95175191.0054
2965.5583
22.4664
1647.0634
24.9555
5191.0054
3007.3903
22.7833
1659.3869
25.14225191.0054
2969.7733
22.4983
1647.3608
24.9600
5191.0054
2979.9758
22.5756
1640.9404
24.86275191.0054
3011.4207
22.8138
1659.7717
25.14815191.0054
2961.201522.4333
1640.2363
24.85215191.0054
3011.0716
22.81111660.4365
25.1581

Process0

ThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThreadThread

0
2
6
9
10
7
4
12
13
15
5
11
8
3
14
1

*************************************************************************************
Application - procedures*************************************************************************************
Cost% Operation (S)Barrier%StartEnd------------------------------------------------------------------------------------6019941 100.0000
60317.3945
37784
0.6276--------------------------------------------------------------------------------------3795973
63.0566
38034.1289
8628
0.22731
123981596.61403989.3936
12895
3.238786
196
1195971.98671198.3140
00.000016
771038771.72551040.8059
00.000016
93103722
1.72301039.2528
00.000016
93
81138
1.3478812.9703
00.00001
203
67445
1.1204675.7719
00.00001
61
66832
1.1102669.629800.000016
115
59766
0.9928598.831400.0000
119
304
39887
0.6626399.651800.000091
351

Application

DGEMMは
63.1%

dgemx_
direct_scf_gmat_cd._OMP_1_
sub_ssss_
sub_spss_
sub_psss_
get_tei_pq_fix_cd_
fmt_
sub_ppss_
monomer_esp_electron_direct._OMP_1_
dimer_oneint_debug._OMP_1_

20

2016/3/1

249 / 253

FMO2-MP2タイミング #3 HIV-1 protease (198残基)
FX-10 @ RIST
OLD
Method
HIV-P(198 res)(1 waterand1 ligand)

点線

Conv-MP2

実線

Full-CD(HF & MP2)

破線

1C-CD
(HF & MP2)

Number of Proc

Elapsed time [second]
Monomer SCF
Monomer MP2

Monomer (Total)

Dimer ES

HIV-P
(198 res)(1 waterand1 ligand)

点線

実線

破線

1C-CD
(HF & MP2)

Dimer (Total)

FMO (Total)

2161.884.2

2354.01079.41748.83794.47198.59552.536

1439.620.6

1568.2

1078.91704.4501.93315.34883.5

36

938.1

6.3

1051.81077.0

882.8

243.1

2244.93296.7(n-p-t)=(node-process-thread)
MethodNumber of Proc(n-p-t)Conv-MP2
36-36-16
36-36-32
72-72-8
Full-CD(HF & MP2)

Dimer MP2

36

32スレッド並列はメリット無（コードの問題）
8スレッド並列で72プロセスの方がベター

FX-100 @ JAXA
FX100

Dimer SCF

Elapsed time [second]
Monomer SCF
Monomer MP2

Dimer (Total)

FMO (Total)

733.1
446.6
818.9

42.2
25.1
57.8

Monomer (Total)
853.3
549.8
916.2

Dimer ES1559.01227.11147.2

Dimer SCF
1184.2679.5
1231.1

Dimer MP2
2132.01593.9
1868.05093.13571.44458.85946.54121.25375.136-36-16
36-36-32
72-72-8

825.8
572.3
831.7

10.1
7.7
12.7

913.8
658.1
883.3

1558.31234.01147.9

851.0
548.0
753.0

192.2
161.6
135.8

2613.31950.92072.83527.12608.92956.136-36-16
36-36-32
72-72-8

556.2
357.5
486.9

3.0
2.3
3.4

637.1
437.8
529.8

1559.71225.01145.2

472.6
300.7
409.0

97.3
85.5
64.6

2146.4
1622.81648.42783.52060.62178.2

21

2016/3/1

FMO2-MP2タイミング #3 HIV-1 protease (198残基)
多ノード利用でも実用性は有222016/3/1

250 / 253

Refs.; Mochizuki et al., Chem. Phys. Lett. 493 (2010) 346.

MP3計算の基本アルゴリズム： 形式的にN6スピンを積分した実装式[2(ia, jb)  (ij, ab)][2(kc, ia)  (ka, ic)][2(kc, jb)  (kb, jc)]
(ij, ab)(ka, ic)(kb, jc)
3.
( i   k   a   c )( k   j   b   c )ijkabcijkabc ( i   k   a   c )( k   j   b   c )E"3h-3p"  (ia, jb)(ik , jl )[2(ka, lb)  (kb, la)],ijklab ( i   j   a   b )( k   l   a   b )E"4h-2p"  (ia, jb)(ac, bd )[2(ic, jd )  (id , jc)],
ijabcd ( i   j   a   b )( i   j   c   d )E"2h-4p"  

最も処理が大変なのは”2h-4p”型の計算： (ac,bd)の露わな生成は困難
Loop over ij‐batch ! size depending on available memory
Loop over s ! parallelized
Form {(ia,jb), (ij,ab), (ik,jl)} ! 1st‐4th quarter transformations
End of loop over s
Calculate partial MP2 energy ! parallelized for ij
Prepare half‐backtransformed 1st‐order amplitude ! parallelized for ij
Perform EEO processing for “2h‐4p” contribution ! parallelized for pq
Calculate partial “2h‐4p” energy ! parallelized for ij
Loop over k‐batch ! size depending on available memory
Loop over s ! parallelized
Form (kc,ld) ! 1st‐4th quarter transformations
End of loop over s
Calculate partial “4h‐2p” and “3h‐3p” energies ! parallelized for ij
End of loop over k‐batch
End of loop over ij‐batch
Sum up “2h‐4p”, “4h‐2p” and “3h‐3p” energies for final MP3 energy
2016/3/1

tijcd 2(ic, jd )  (id , jc) 相関振幅を計算,
i   j  c   dtijqs   cqc csd tijcd ,添字を逆変換X ijpr   ( pq, rs )tijqs .

Fock行列的な処理（EEOと呼ばれる）X ijab   c pa crb X ijpr .

添字を変換

cd

qs

pr

・ 2重(ijとk)のバッチ構造（メモリが少ないとコスト高）
・ 可能な限りDGEMMを使用

23

CDによるMP3計算 (4p-2h部分)： 形式的にM*N5





(ia, jb) (ac, bd ) 2(ic, jd )  (id , jc)    
ij             j   a   b  cd
j
c
d 
 i
 ab i



2





 1     t    (ac, bd )t   
i j

ij

 ab


2

ab
ij

cd
ij

cd



 1     t   B
i j

ij

 ab


2

ab
ij

 Ic

I , ac 1     t    B
i j

ij

 ab


2

ab
ij

I , acIc

 ij 

 1     t  K  
i j

ab

ij

2

ab



元の4p-2h式をCDで近似  BI ,bd tijcd     d(ac,bd)をB行列での積和に変更

AI ,ijbc   

積和処理を繰り返す

最後abの和となるのは通常の2電子積分と同じ

 1   e
i j

ab
ij

・ 3p-3hもijループ内で同様に処理
・ DGEMM行列積演算が支配的・ 通常積分と違い、閾値篩は無・ 2p-4hはabループで駆動

ij ( 4 p  2 h )ij・ full CDの場合、展開長(Iの長さ）MはN2的になってしまう
・ CD展開を1中心化するとMはN的にはなるのだが…
・ DGEMMの性能が高いことを期待してベンチマークを実施
24

2016/3/1

251 / 253

FMO2&3-MP3タイミング #4 Ala9Gly (10残基)
FX-10 @ RIST

MP2

abinitmp_smp-opn1-160102
FX10#Thread=16 / intra-node OpenMP parallelism
NEW
Ala9Gly(10 res)

MethodRegular-MP2

Energy calc

Full-CD-MP2

Energy calc

1CCD-NP2

Energy calc

MP3

MP2/6-31G*
Number
of
Proc
1
2
5
10

Dimer (Total)

FMO (Total)

763.4
441.8
214.9
92.2

48.5
26.4
12.8
7.8

815.4
470.1
228.5
100.6

9.0
4.6
1.9
1.0

298.8
151.0
61.1
31.0

609.2
302.6
117.7
59.5

982.1
490.5
202.5
103.0

1797.5
960.6
430.9
203.6

1
2
5
10

300.6
157.0
68.2
55.3

8.5
4.3
1.9
1.7

312.6
163.2
70.9
57.6

9.0
4.6
1.9
1.1

254.4
127.5
51.3
25.9

49.5
24.4
9.9
5.2

317.6
158.7
65.2
33.0

630.2
321.9
136.2
90.6

1
2
5
10

127.4
66.1
28.8
24.2

2.4
1.2
0.5
0.5

133.2
69.2
30.2
25.3

9.0
4.6
1.9
1.0

110.6
55.1
21.9
10.9

23.5
11.6
4.6
2.4

147.7
74.6
30.8
15.9

280.9
143.8
61.0
41.2

Monomer SCF

Monomer MP2

Monomer (Total)

Dimer ES

Dimer SCF

Dimer MP2

Full CDではMP2比で10倍となる残念な結果に…（通常MP3が上手く出来過ぎている?）abinitmp_smp-opn1-160102
FX10#Thread=16 / intra-node OpenMP parallelism
NEW
Ala9Gly(10 res)

Elapsed time [second]

MethodRegular-MP3

Energy calc

Full-CD-MP3

Energy calc

1CCD-NP3

Energy calc

MP3/6-31G*
Number
of
Proc
1
2
5
10

Elapsed time [second]
Monomer SCF

Dimer (Total)

FMO (Total)

761.4
442.1
215.0
91.9

Monomer MP2
87.2
43.8
19.9
19.1

Monomer (Total)
852.1
487.8
235.7
111.7

Dimer ES
9.0
4.6
1.9
1.0

Dimer SCF
299.7
151.0
59.1
27.3

Dimer MP3
2650.81336.8426.2
189.93024.41524.9648.7
427.5

3876.52012.7
884.4
539.2

1
2
5
10

300.6
157.3
67.9
55.0

74.9
43.5
24.5
24.6

379.0
202.7
93.2
80.2

9.0
4.6
1.9
1.0

254.7
127.9
47.0
21.1

6335.73079.7992.5
412.8

6604.1
3388.51480.7875.76983.03591.21573.9
955.9

1
2
5
10

127.1
66.2
29.2
24.2

33.1
19.2
10.9
10.9

163.6
87.3
41.0
35.7

9.1
4.6
1.9
1.0

110.6
54.8
20.1
9.0

2982.81448.0459.6
193.4

3107.21602.3697.5
420.3

3270.71689.6
738.5
456.0

25

2016/3/1

FMO2-MP2タイミング #4 Ala9Gly (10残基)
スケール性は良好

26

2016/3/1

252 / 253

FMO2-MP3タイミング #4 Ala9Gly (10残基)
残念ながらCDのメリットが見えない…

27

2016/3/1

ABINIT-MPの性能評価のまとめ、これからの課題■ 現状・ 最も利用度の高いFMO2-MP2/6-31G*計算は及第の性能 （「京」、FX）→ FX-100では実タンパク質のMP2ジョブもルーチンに実行可能→ 複数の計算処理から構成されるFMOジョブでも要所を押さえることが肝要
・MP3は精度向上の上では有用 （MP2.5スケーリング）→ 通常積分の場合でもDGEMMによる行列積が支配的、閾値篩も有効→ CDは現状ではコスト高、展開長MをほぼNと出来るRIの導入がマスト■ 今後
・ FXや「京」などを利用してベンチと改良作業を続ける→ 大型のタンパク質の実行テストの必要性→ エネルギー微分など他の計算機能の評価
・ ABINIT-MPのOpenシリーズへの移行と性能向上 （FS2020プロジェクト関連）→ 2016年度内にCDからRIに移行→ 「京」では20-30％効率を1000-2000ノードで担保したい→ DFT法などの新規計算機能の導入
・ 「京」などでのcapacity computingへの対応→ いわゆるパラメータスタディや統計ジョブの扱い （HPC/PFと連携）→ ジョブの自動投入/回収のシステム
・ ABINIT-MPソース共有コンソーシアムの立上げ （2015年度末）
2016/3/1→ 産官学の構成、産業界への普及を促進
253 / 25328