マルチコアからメニーコアへ、我々は使いこなせているか？
- ポストペタアプリ性能WG報告 -高木 亮治
ポストペタアプリ性能WGまとめ役
宇宙航空研究開発機構

内容• WGの概要• アプリケーション事例集• まとめ2

WGの目的• 「京」、FX10からFX100への流れ
ノード内マルチコアの大規模クラスタ
マルチコア→メニーコア- 京：8コア、FX10：16コア、FX100：32コア、FX103?
：?コア

SIMDの拡張- 京、FX10：2SIMD、FX100：4SIMD、?：?SIMD• メニーコア、SIMDの使い方に関して情報共有
京・FX10→FX100向け- 性能評価- 高速化チューニング
3

活動期間とメンバー• 活動期間：2014年3月～2016年2月（2年間）、のべ26名
氏名
石井克哉(担当幹事)

所属機関（2016年2月現在）

氏名

名古屋大学

南高木 亮治(まとめ役)

宇宙航空研究開発機構

望月 祐志

立教大学

坂下

宇宙航空研究開発機構

井上晃(まとめ役)

富士通(株)深沢圭一郎

京都大学

青木正樹

富士通(株)

河合諏訪東京理科大山中栄次

富士通(株)

堀之内成明(株)豊田中央研究所(-2014年12月)

三吉 郁夫

富士通(株)

平井宏俊(株)豊田中央研究所(2015年1月-)

千葉修一

富士通(株)

梅田隆行

名古屋大学

内藤俊也

富士通(株)

荻野 正雄

名古屋大学

本藤 幹雄

富士通(株)

井戸村泰宏

日本原子力研究開発機構

錦龍生

富士通(株)

剣崎博生

理化学研究所向井優太

富士通(株)

似鳥啓吾

理化学研究所森重博司(オブサーバ)

富士通(株)

野田 茂穂

理化学研究所

市川 眞一(オブサーバ)

富士通(株)

雅秀
浩志

一生

所属機関
理化学研究所

4

活動内容の概略• 2年間で全10回の会合• 活動内容：会員アプリの性能評価報告（各アプリ2.5回）- アプリ紹介、京・FX10での評価、FX100での評価

富士通からの情報提供- Post-FX10(=FX100)の基礎性能、PAツール• 成果：
成果報告書「アプリ高速化事例集」(PDF)
PRIMEHPC FX100チューニングガイド
5高速化事例集（会員から）様々な分野、計算モデル、手法のアプリを評価・高速化チューニング
••••••••••••

圧縮性流体解析プログラムによるFX100の性能評価と高速化チューニング
ハイブリッド非構造格子CFDソルバのメモリ階層構造への対応および有限体積法における再帰参照とSIMD化
惑星磁気圏MHDコードの性能評価
LexADV-AutoMTおよびAutoLinASライブラリの性能評価（ADVENTURE）
LAMMPS/ReaxFFのFX100における性能評価とチューニング（分子動力学）
2次元プラズマ粒子(PIC)コードの測定評価および宇宙プラズマ５次元ブラソフコード
Vlasov5dの測定評価
電磁場解析コードADVENTURE_Magnetic性能評価
核融合プラズマ流体解析コードGT5DおよびGKVの性能測定
生体分子粗視化シミュレータCafeMolのFX100での性能評価
N体計算ベンチマーク
NGSデータ処理プログラムBWAの評価について
FMOプログラムABINIT-MPの富士通系マシンでの性能評価

6高速化事例集（富士通から）
原因分析、システムへのフィードバック• フラグメント分子軌道法「ABINIT-MP」d関数積分ルーチンの結果異常について• 核融合プラズマ流体解析「GKV」SSL2の性能改善について• 圧縮流体解析「UPACS-L」tune1コード:プ
レ処理の性能劣化について• 電解磁場解析「ADVENTURE_Magnetic」
DAXPYのSIMD化について• 圧縮流体解析「UPACS-L」レジスタの不足、大きなループボディに対する最適化の適用
7

別冊 PRIMEHPC FX100 チューニングガイド
第0章
第1章
第2章
第3章
第4章
第5章
第6章
第7章
第8章
第9章

PRIMEHPC FX100 チューニングガイド
ハードウェア編
プログラム開発環境とプログラミング概略
ラージページ編
Fortran編
C/C++編PAイベント編
チューニングツール編
ノード内チューニング編
MPIおよびノード間チューニング編
8

アプリケーション事例集9

MHDコードまとめ 京都大学 深沢圭一郎
FX100を利用して、MHDコードの性能評価を行った
基本性能測定• HPC2500からFX10まで効果的だった配列順序替えはあまり効かない→ベクトル機的な側面• スケーラビリティは計測時は不安定だった
形状指定を行っていなかったから？

最適化• FX10に比べFX100ではL1D$容量、ウェイ数、スループットの倍増、およびラインサイズ2倍のため実効性能が向上している。
• ループや文の分割を行うことで、コンパイラの最適が促進され、性能向上。
• プロセス分割の調整、サイクリック並列化によりL2キャッシュミスが減少。
• 配列分割により、キャッシュヒット率が向上。
• タイリングはSIMD最適化が効かず、性能向上はなかった。

ベクトル（SIMD）最適化後に、キャッシュ最適化を行うことが効果的
10

連続体力学向けドメイン特化言語

AutoMT(おてもと）

諏訪東京理科大学
河合浩志

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

DSL
スクリプト

解析領域全体に関する行列方程式のコード

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

言語仕様策定独自テキスト形式
LaTeX形式

トランスレータ開発（小規模）行列・テンソルライブラリ
特定アーキテクチャ向け
性能最適化

Intel系向け実装

HDDMベース
大規模線形代数
ソルバーライブラリ（ADVENTURE)

AutoMT（おてもと）
CUDAによる実装

京、FX10系向け実装

MIC向け実装

その他…

LAMMPS/ReaxFFのFX100における性能評価とチューニング
3600原子（メタン400分子、酸素800分子）の系で評価・反応力場の計算にpow、expが多数あり→組込関数のインライン展開により性能向上（図１）・力場計算部分にロードインバランスあり→各プロセッサが担当するサブ領域のサイズ・形（原子数）を調整（LAMMPS のdynamic load-balancing 機能）することでロードインバランスが改善（図２）・ウィークスケーラビリティは良好（問題規模を64 倍にしても計算時間の増大は1.6倍程度）、大規模計算でも性能が出せる（図３）

図２

図１

図３

株式会社豊田中央研究所
平井 宏俊

VLASOV5d（プラズマ分布関数コード）
及びPIC2d(プラズマ粒子コード)の性能測定(ex. 40^5 ~ 4GB)

 VLASOV5d: 5次元を扱うコード⇒各次元のループ長が短い
・$!OMP DO COLLAPSEを用いて多重ループをスレッド並列化することで、短いループ長でもスレッド化のオーバーヘッドを軽減できる。
・富士通コンパイラの!OCLで loop unrollの回数をループ長で割り切れる値に設定すると演算が速くなる。（40の場合は10とか8が高速）
・5次元配列の転置： f(I,j,l,m,n) ⇒ f(l,m,n,I,j) は、コンパイラに任せると最適なループの入れ替えをしてくれる。 40^5のデータは0.5秒以内で転置が終了。

 PIC2d: 粒子が格子内を自由に動き回る(particle-in-cell)ため、粒子の位置から電磁場格子へのデータアクセスがランダム・粒子データをソートして連続的なデータアクセスにすることで、90%以上のスレッド並列スケーラビリティを得る。
・CX400では、富士通コンパイラのほうがifortよりもスレッド性能が良い。
・IvyBridgeとHaswellは性能があまり変わらない。2ソケットサーバでは、１ノード1プロセスは遅く、2プロセスが速い。
梅田隆行(名古屋大学)

電磁場解析コードADVENTURE_Magnetic性能評価
荻野正雄(名古屋大学)● コードの概要

 Maxwell方程式から導かれる静磁場, 渦電流, 高周波電磁界について有限要素解析を実施
 四則演算等を関数形式マクロ化し, 実数と複素数それぞれのケースでのコードを共通化
 線形方程式は, 領域分割法から導かれるSchur補元方程式を反復解法で求解● コードの主要部分疑似コード ● 非定常渦電流(実数)と時間調和渦電流(複素数)の測定結果
Non-steady (Real)Time-harmonic (Complex)
𝐟𝐨𝐫 𝑝 = 1 𝑡𝑜 𝑁 𝐝𝐨 プロセス並列
𝑝𝑝

𝐟𝐨𝐫 𝑖 = 1 𝑡𝑜 𝑁𝑑𝑜𝑚 𝐝𝐨 スレッド並列
𝐬Ip,ip,ip,ip,i= 𝐬Ip,ip,i← 𝐊 BB 𝐩B

pp𝐪Bp,i0.70

1.64● 時間調和渦電流問題解析(複素対称線形方程式)の測定結果← −𝐊 IB 𝐩B

solve 𝐊 II 𝐭I

FLOPS / PEAK [%]上段は経過時間[sec], 下段はピーク性能比p,ip,i+ 𝐊 BI 𝐭 Ip,ip,ip,ip,iK

FX10FX100

asis626(5.28 %)424(4.22 %)187(1.64 %)

ocl指定,手動ループ交換,realloc呼出削減

441(7.47 %)

298(5.98 %)126(2.43 %)XOS_MMM_L_ARENA_
LOCK_TYPE=0指定--100(2.95 %)

𝐪B ← 𝐪B + 𝐑 B 𝐪B
𝐞𝐧𝐝 𝐟𝐨𝐫p𝐪 B ← 𝐪B + 𝐪B
𝐞𝐧𝐝 𝐟𝐨𝐫※ 各CPUコアが比較的小規模な行列ベクトル積や線形方程式求解の計算を繰り返す

 複素数は実数に比べて要求B/F値が低く, 性能が出やすいアプリ
 それでもメモリ律速で, FX100ではピーク性能比が大きく低下
 スレッド内でメモリ確保・解放を繰り返す場合は,
XOS_MMM_L_ARENA_LOCK_TYPE環境変数の指定が有効サイクルアカウンティング結果の比較(kernel_p区間)
FX100における通信隠蔽の性能評価
1.0E-022.0E-17Thread 0

Thread 1

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8-1.0E-02

unroll+overlap
版 ⇒通信スレッド解除版
差分演算カーネルにおける袖通信の隠蔽

ﾒﾓﾘ･ｷｬｯｼｭﾋﾞｼﾞｰ待ち

[秒 ]

[秒 ]

浮動小数点ロードメモリアクセス待ちストア待ち井戸村泰宏(JAEA)
浮動小数点ﾛｰﾄﾞL1Dｱｸｾｽ待ち

整数演算待ち浮動小数点演算待ち

バリア同期待ちその他の待ち1命令コミット

2/3命令コミット

整数ロードメモリアクセス待ち

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

ストア待ち

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

浮動小数点ﾛｰﾄﾞL1Dｱｸｾｽ待ち

整数演算待ち浮動小数点演算待ち

バリア同期待ちその他の待ち1命令コミット

2/3命令コミット

ﾒﾓﾘ･ｷｬｯｼｭﾋﾞｼﾞｰ待ち

8.0E-02

整数ロードメモリアクセス待ち

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

7.0E-028.0E-02•• マスタスレッドの演算数はほぼゼロ• 演算と通信のコストがほぼ同じ条件
全スレッドで演算数は同等⇒ マスタスレッドは通信処理に専念• コア数で割り切れるカーネルループ長• マスタスレッドは通信処理も実行• 2種類の通信隠蔽手法

6.0E-02
7.0E-02

通信オーバラップ効果の評価(3/3)
5.0E-02
6.0E-02

4.0E-02
5.0E-02

3.0E-02
4.0E-022.0E-02
3.0E-02

 OpenMPによる通信スレッド実装⇒ ただしkernel_p区間のスレッド並列ループは
 アシスタントコアの利用
静的スケジューリング

1.0E-022.0E-02

サイクルアカウンティング結果の比較(kernel_p区間)
2.0E-17
1.0E-02⇒
通信スレッド解除
版
性能評価 unroll+overlap版
通信スレッド解除版⇒ (通信促進あり)• 全スレッドで演算数は同等
オリジナルカーネル• マスタスレッドの演算数はほぼゼロ
全スレッドで演算数は同等• 通信処理後に差分演算を実施

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8

Thread 0

Thread 1

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8-1.0E-02[秒 ][秒 ]8.0E-02[秒 ]8.0E-02

ﾒﾓﾘ･ｷｬｯｼｭﾋﾞｼﾞｰ待ち

整数ロードメモリアクセス待ち

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

ストア待ち

浮動小数点ロードL2アクセス待ち
ﾒﾓﾘ･ｷｬｯｼｭﾋﾞｼﾞｰ待ちバリア同期待ち浮動小数点ロードL2アクセス待ち
ﾒﾓﾘ･ｷｬｯｼｭﾋﾞｼﾞｰ待ちバリア同期待ち浮動小数点ロードL2アクセス待ち

浮動小数点ﾛｰﾄﾞL1Dｱｸｾｽ待ち
整数ロードメモリアクセス待ち
その他の待ち浮動小数点ﾛｰﾄﾞL1Dｱｸｾｽ待ち
整数ロードメモリアクセス待ち
その他の待ち浮動小数点ﾛｰﾄﾞL1Dｱｸｾｽ待ち

整数演算待ち浮動小数点ロードメモリアクセス待ち
1命令コミット
整数演算待ち浮動小数点ロードメモリアクセス待ち
1命令コミット
整数演算待ち浮動小数点演算待ち
ストア待ち
2/3命令コミット
浮動小数点演算待ち
ストア待ち
2/3命令コミット
浮動小数点演算待ち

バリア同期待ちその他の待ち1命令コミット

2/3命令コミット

7.0E-028.0E-02

6.0E-02
7.0E-02
6.0E-02

5.0E-02
6.0E-02
5.0E-02

4.0E-02
5.0E-02
4.0E-02

3.0E-02
4.0E-02
3.0E-02⇒ ただしkernel_p区間のスレッド並列ループは• Master構文による通信スレッド実装
スレッド数が2冪、動的スケジュー
静的スケジューリング
• Dynamic分割による負荷分散均等化

2.0E-02
3.0E-022.0E-02

1.0E-022.0E-02
1.0E-02

0.0E+00
1.0E-02

Thread 0

Thread 1

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8

Thread 0

Thread 1Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8

Thread 0

Thread 1

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8

2.0E-17

リング不要、ループ一重化も不要• マスタースレッドはほぼ通信を担当し、マス⇒-1.0E-02
2.0E-17-1.0E-02

通信スレッド解除版⇒ (通信促進あり)
タースレッドの演算をスレーブで分担
通信スレッド解除版• Static分割による均等負荷分散• 通信処理をアシスタンコアに移行、ただし、スレッド数が2冪、動的スケジュー⇒ ただしkernel_p区間のスレッド並列ループは移行処理でマスターに5%程度の遅れ
静的スケジューリング
リング不要、ループ一重化も不要

Thread 1

7.0E-02• マスタスレッドは通信処
理理も実行⇒ マスタスレッドは通信処に専念•
マスタスレッドの遅れは5%程度
OpenMPによる通信隠蔽•• 全スレッドで演算数は同等
アシスタントコアによる通信隠蔽
全スレッドで演算数は同等• Directive挿入のみの最小限の変更•• マスタスレッドの遅れは5%程度
マスタスレッドは通信処理も実行

Thread 0-1.0E-02
0.0E+00

7-1.0E-02

[秒 ]
[秒 ]
8.0E-02

ﾒﾓﾘ･ｷｬｯｼｭﾋﾞｼﾞｰ待ち

整数ロードメモリアクセス待ち

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

ストア待ち

浮動小数点ロードL2アクセス待ち
ﾒﾓﾘ･ｷｬｯｼｭﾋﾞｼﾞｰ待ちバリア同期待ち浮動小数点ロードL2アクセス待ち

浮動小数点ﾛｰﾄﾞL1Dｱｸｾｽ待ち
整数ロードメモリアクセス待ち
その他の待ち浮動小数点ﾛｰﾄﾞL1Dｱｸｾｽ待ち

整数演算待ち浮動小数点ロードメモリアクセス待ち
1命令コミット
整数演算待ち浮動小数点演算待ち
ストア待ち
2/3命令コミット
浮動小数点演算待ち

バリア同期待ちその他の待ち1命令コミット

2/3命令コミット

8.0E-02

7.0E-02
7.0E-02

6.0E-02
6.0E-02

5.0E-02
5.0E-02

4.0E-02
4.0E-02

3.0E-02
3.0E-022.0E-022.0E-02

1.0E-02
1.0E-022.0E-17Thread 0

Thread 1

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8

Thread 0

Thread 1

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Thread 7

Thread 8

0.0E+00-1.0E-02-1.0E-02

生体分子粗視化シミュレータCafeMolのFX100でのチューニング
• タンパク質/DNA複合体

理研ACCC
検崎博生• ネイバリングリストを用いた計算• 最も大きな配列(粒子数x100-10,000)• タンパク質：アミノ酸を1粒子に粗視化• DNA：糖、塩基、リン酸を1粒子に粗視化 • リストをMPIプロセス毎に分割• MPIプロセス内はopenMPで並列計算• ヌクレオソーム1個の系：1,854粒子• FX100でのベンチマーク結果• FX10に比べて、同じ16コアで1.5倍程度性能向上• 4,8,16スレッド並列で性能がよかった• 自動並列化オプションで1,2割の性能向上• 更なるチューニングは、SIMD化困難なループが多数あり挫折

N体計算ベンチマーク

理化学研究所計算科学研究機構
似鳥啓吾• Hermite積分法によるN体計算のベンチマークコード• https://github.com/nitadori/Hermite• 演算数に比べてメモリアクセスは少ない• 細かな同期が多発する（独立時間刻み法のため）• 各種アーキテクチャに向けて手動チューニング
• AVX, HPC-ACE, Xeon Phi KNC, CUDA, AVX2, HPC-ACE2• SIMD組込み関数とC++クラスラッパを用いた• 機種依存のコード開発だが最低限の可読性と生産性を確保したかった• 苦労した点• Fujitsuコンパイラに構造体がレジスタに載るコードを出してもらうこと（最近とても良くなった）• FX100でSIMD組込み関数が当時は正式サポートされていなかったこと（<mxintrin.h>を利用した）

NGSデータ処理プログラムBWAの評価
野田茂穂(理研)

ゲノムDNAシステム
NGSを使って塩基配列解読
生データ（画像データ等）
一次解析：Base caller
生データを配列データに変換
大量の断片
配列データ

2次解析:
Assemble & Mapping

ここは装置

全長配列データ

NGSでは、計測結果の断片的なゲノム配列を処理し全長配列データを得る。
NGSが大量に導入されゲノムデータ処理に必要なコンピューティングパワーが増大している。

この処理を対象
名前

BWA

Bowtie2

SOAP2

アルゴリズムBWT(BurrowsWheelerTransform)

BWT

BWT

挿入欠失(In/Del)

検出可能

検出可能

検出不可能

処理速度

速い

とても速い

速い

精度

良い

BWAより悪い

BWAより悪いスレッド並列化

pthread(ｖ0.5，v0.6)
SSE2(v0.7)

pthread

SSE

ライセンス

GPL v3GPL v3academic freebinary

FX10と「京」で動作する、BWA（NGSAnalizerで使用）の詳細プロファイルを取得

FX10

FX100

性能向上率

実行時間[s](Elapse)16885.48 17576.08

0.96

実行時間[s](User)

16801.84 17176.89

0.98

実行時間での比較
・FX10と比較してFX100では(Elapse-User)時間(=IO時間)が大きい。
・IO時間を除いてもFX10→FX100で0.98倍

並列性能
1スレッド実行→32スレッド実行で13.79倍性能向上
16スレッド実行→32スレッド実行で1.44倍性能向上→理想値より性能向上率は低いが並列性は高い

フラグメント分子軌道（FMO）プログラムABINIT-MPによるベンチマーク事例 （望月@立教大）
・ FMO法は対象系をフラグメント分割して並列処理
・ エネルギーはフラグメント単体とその対で構成
・ 創薬分野の相互作用解析などに向く（ΔEIJ利用）
E   EIJ  ( N f  2) EI
I J（書換可→）IE   EIJ   E ' I
I JIABINIT-MPの文献 ; Phys. Chem. Chem. Phys. 16 (2014) 10310.

Target system
Fragment momer(or dimer)

Parallelized by fragment
indices

MPI 並列→OpenMP 並列→
Parallelized by integral
indices

Processor group

フラグメント総数 203
FMO-MP2/6-31G* ジョブ【HIV-1プロテアーゼ（198残基）＋リガンド】( pq, rs)   LI , pq LI ,rsI

𝑋𝐼,𝑖𝑞 =

𝐿𝐼,𝑝𝑞 𝐶𝑝𝑖
𝑝𝐵𝐼,𝑖𝑎 =𝑋𝐼,𝑖𝑞 𝐶𝑞𝑎

積和展開基底I には軌道積を使う（Full）が、1中心の制限も可能（1C）𝑞

CD（コレスキー分解）では2電子積分を積和分解→ DGEMM実行が増→ ジョブ時間は4割減（FX-10ではフラグメメントあたりに16スレッド）（FX-100ではノード数-プロセス数-フラグメントあたりのスレッド数）

UPACS-Lite@FX100 (高木@JAXA)• SIMD化の促進

 一時配列のスカラー化
 ベクトル表記の展開

3160
1098765432
10O
gcphysdqdt2
MFGS
convect-alloc
convect-pre

G

Gt

Ht

LOAD modules
convect-muscl
convect-flux
convect-post
viscous-alloc
viscous-pre

It

Jt

Kt

viscous-cfacev
viscous-flux
viscous-post
ALL• AOSからSOAへ• OpenMPのcollapse（多重ループの一重化）• 配列、多重ループのイン
デックス順序の変更• 重複配列の削除• サブルーチン（ループ）の融合• 課題： ループボディの増大- レジスタ不足- 命令数過剰20

FX100の使い方@WG後 (高木@JAXA)
メモリバンド幅ネックのアプリに対して• HMCの特性：LOADとSTOREが別々
240GB/s×2=480GB/sだが非対称の場合240GB/s• 上記の対策としてXFILLの活用

FILLを使うにはループ長（デフォルト：256）が必要
LDXFIL
STL

012345670-240

240

240

240

240

240

240

1240

480360320300288

280

2740-240240

240240

240

240

240

1240

240240240240240

240

240

ありなし

21

会員の声（1/2）• 高速化チューニング：ある程度高速化ができたが、SIMDへの対応が不十分（FortranでもIntrinsicが欲しい）。
キャッシュの動きの理解が進んだ。
SIMD、SWP、PFの最適化がかなり進んだ。
DGEMM加速の有効性が確認できた。
当初低い性能だったが、それなりの性能にまで高速化ができた。

• ツール：
詳細PAは良い。MPIの情報も。
22

会員の声（2/2）• ツール（続き）：
 プロファイラ情報の初見で性能劣化の原因を推定するのが困難。
 ツール利用の良いきっかけになった。
 便利に使えたが、今後コア等が増えたときに有用な情報を読み取れるかは不安。
 プログラムの中の区間で情報が取れるのは便利。使い方に慣れるのに時間がかかる。

• その他：
 早く次期システムの提案を。
 メモリバンド幅ネックのアプリでSIMD化率を上げることに固執するのは意味がないことがわかった。
 プロファイラのマニュアルをもう少し簡単にしてほしい。
23

総括（1/2）• 性能評価と同時に、各アプリの特性、会員の技量・エフォートに応じて様々なチューニングを適用し高速化を図った。
依然として試行錯誤が主。

• 前身のWG時に比べてプロファイラー、詳細PAツールなど性能評価ツールが比較的使いやすくなった。
ユーザーがこれらのツールを駆使して性能評価・分析が行えるようになりつつある？
でも、分析はできたけど対策は？

• 新機能の活用

アシスタントコアを使った通信と計算のオーバーラップ24

総括（2/2）• 「マルチコアからメニーコアへ、我々は使いこなせているか？」ある程度使いこなせている場合もあるが、あまり使いこなせていないのでは？（by 高木）- 「個人の感想であり（メニーコア、SIMDの）効果・効能を否定するものではありません」

FX100は手を入れれば高速（by 高木）- 「個人の感想であり効果・効能を保証するものではありません」• ツールの改良と同時にユーザーのレベルアップが継続的に必要単なるユーザーサポートとは異なるWGの存在価
値
25

まとめ
• 京・FX10およびFX100などのマルチコア/メニーコアクラスタを対象としたアプリケーションプログラムの性能評価および高速化チューニングを実施し、各アプリの分析・高速化のノウハウを共有化することができた。
• ポストペタからエクサに向けて計算機はます
ます複雑化するため、[前回WGでも言ったが] H/W・システム・コンパイラ開発者等の支援の下、ユーザーが主体的に性能評価・高速化チューニングを実施する本WG的活動が継続されることを期待する。
26

謝辞• 2年間のWG活動に参加していただいた会員の皆様、富士通担当者、SS研事務局の皆様に感謝の意を表します。
• WGでは以下の環境を利用させていただきました。改めてここに感謝の意を表します。
 スーパーコンピュータ「京」 宇宙航空研究開発機構 JAXA Supercomputer System（FX1）、
JAXA Supercomputer System 2（FX100）
 核融合科学研究所 プラズマシミュレータ（FX100）
 九州大学（FX10）
 高度情報科学技術研究機構（FX10）
 諏訪東京理科大（PC, Haswell）
 東京大学 Oakleaf-FX（FX10）
 名古屋大学（CX400/250, CX400/2550, FX10, FX100）
 理化学研究所 RIKEN Integrated Cluster of Clusters（PRIMERGY RX200 S5, PCサーバ）、SCLS計算機システム（FX10）、
HOKUSAI GreatWave（FX100）
 富士通社内機27