学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書

jh190039-ISH

高性能，高生産性を実現する大規模メモリ・並列処理
システムソフトウエアの研究
緑川 博子（成蹊大学）
概要
大規模計算クラスタシステムにおいて，巨大な大域共有メモリを実現するランタイムシ
ステム mSMS とそれを利用するための API を構築し，高性能な並列プログラムを容易に開発できる環境を実現した.C を基本とする他の PGAS 言語との比較では，プログラム記
述性と実行性能ともに，最も高性能であるばかりか柔軟性の高いプログラム記述が容易にできることを示した．また従来，困難であったクラスタにおけるグローバルツリーを利用する Barnes-Hut を実現し，大規模 N 体問題を容易に記述し，高性能実行できることを示した．音響解析処理では，記述の容易さと性能を両立できる事が明らかにした．さらに，クラスタにおけるトランザクショナルメモリの実現にむけての第一次実装と評価を行った．最後に，消費電力低減に向けて，大規模システムにおける GPU 消費電力のばらつきを調査し，GPU 消費電力低減のための指針を示した．
1.

共同研究に関する情報(1)

制御緩和方式の検討と実装

共同研究を実施した拠点名

東京工業大学 (Tsubame3.0)

2.

九州大学 (ITO-B)(2)


研究の目的と意義

大規模クラスタシステムにおいて，以下の４つを共同研究分野実現するシステムソフトウエアの構築を目的とする．

超大規模情報システム関連研究分野(1)計算ノードメモリを超える大域共有アドレス空間の実現と大規模データの高速アクセス，(2)クラス(3)

参加研究者の役割分担

タシステムにおける並列プログラム開発の生産性向

成蹊大学グループ：

上，(3)従来の配列の同期的並列処理にとどまらず，

緑川 博子：高性能計算・システムソフトウエア設

不規則構造データに対する非同期並列処理の効率実計，構築，評価

行，(4)消費電力低減．

阪口 裕梧：mSMS むけ並列処理 API 開発

これにより，幅広い応用分野における大規模デー

九州工業大学グループ：

タの高性能計算が可能となる．

高橋 公也：音響解析

3.

田畑 諒也：mSMS による音響 FDTD(2,4)法の高効率実装手法の開発

当拠点公募型研究として実施した意義
第一に，応用分野からシステムソフトウエア，省

電気通信大学グループ：

電力などの異なる分野の研究者によるコラボレーシ

三輪 忍：システム消費電力調査，削減

ョンが可能であったこと．第二に，各拠点の高性能

大八木 哲哉：mSMS＋GPU 消費電力調査

計算システムにおいて，普段，予算的に難しい多数

名古屋工業大学グループ：

ノード，多数 CPU，GPU を利用して実装実験，性能評

津邑 公暁：トランザクショナルメモリ(TM)による価ができたことである．具体的には，TSUBAME3.0 で実行方式の検討は，1 ノードに搭載された 4GPU を連携する NVLINK な

飯田 凌大，川口 優樹：TM のハード・ソフト実どを利用する実験，多数ノード利用による大規模メ

装の協調方式の検討と実装

モリを扱う大規模シミュレーション，これまでにな

二間瀬 悠希，小林 龍之介：TM における一貫性

い多数 GPU を利用した大規模消費電力評価実験など

1

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書が可能であった．また，ITO-B では，準占有利用によたスレッド数を用いた最適値を示している．この結り ITO の利用規定範囲で、長時間の音響解析シミュ

果，全ノードにおいて，SMint が高性能を獲得していレーションを行うことが可能であった．また，ITO-B

る．また，各言語の記述性の詳細は紙面の都合で割は,CPU に Skylake-SP を搭載しており，トランザク

愛するが，全体のソースコードと性能の比較を表１

ショナルメモリ命令を利用することも可能であった． に示す．
（詳細は[1][6]を参照）
UPC グローバル型記述（表 1,1 行目）では，記述が4.
5.

前年度までに得られた研究成果の概要

シンプルになるものの，実行性能は劣っている．ま

今年度採択のため,該当せず．

た，実際に利用できるグローバルサイズに実装上の今年度の研究成果の詳細制限があり，全体として数十 GB を以上のグローバル(1)分散共有メモリ並列システム（mSMS）の通信高性

データを扱うことが難しい．一方，XcalableMP は，能化および高性能 API の構築と他言語との比較

記述も簡単で，SMint と同様に高性能で，大規模なグ遠隔データの高速プリフェッチ機能を提供する新ローバルデータ宣言も可能であるものの，実際にア

たな preload,overload 関数，グローバルデータへのクセルできる領域は，自ノードの隣接領域に限られファイル入出力関数などを開発した．

ており，ステンシル計算のような近傍処理応用以外

また,逐次プログラムにpragma文を加えるだけで,は実装できず，適用可能な応用は非常に限られる．

容易にマルチノード並列プログラムに変換できる

UPC で 大 規 模 な グ ロ ー バ ル デ ー タ を 扱 うに はAPI として SMint を提案し，OpenMP や OpenACC と自upc_alloc を利用したポインタによる記述（表 1,3 行

由に組み合わせて，利用環境や応用分野に応じてマ目）が必要であるが，UPC では言語仕様上，shared

ルチノードマルチコアプログラミングが容易にでき

data とノードローカルデータは型が異なり,合計４る環境を構築した．SMint(mSMS)では，定義できるグ
ローバルデータサイズに制限がなく（C ポインタの扱える範囲までのデータ領域が定義可能で，実際には，利用ノード数と各ノードの物理メモリ容量の積まで．），グローバルデータのどのような領域へも各ノードの各スレッドからアクセスできる．
C を基本とした代表的な PGAS 言語である UPC と
XcalableMP を Tsubame3 に実際にインストールして詳細に比較調査を行った[1,6]．図 2,3 にその結果の図１ 各種言語（UPC,XcalableMP,MPI,SMint）の性能比較

一部を示す.比較には，比較的小規模な二次元データ（各言語のそれぞれの最適スレッド数で実行したときの各ノー

５点ステンシル計算を採用した．この理由は，後述

ド数での５点ステンシル計算の Tsubame3 の性能）のように，１）UPC のグローバル記述で利用可能な

表１ 各種言語（UPC, XcalableMP, SMint）の比較

グローバルデータサイズには制限があり大規模デプログラムの記述性ータ処理ができないこと，２）XcalableMP では，実各種言語

逐次コードに付加

行数

際にはグローバルデータのどこにでもアクセスで
UPC (Global view model)

きるわけではなく，各ノードの隣接したグローバル
データにしかアクセスできず，記述できる応用が限UPC (Local view model)

4
20

増加率
5%
20%

性能

特徴

SMintに対する 扱えるグローバルデータサイ
実行時間の比大きいほど悪い

3.5 - 10.4
1.2 - 8.6

ズ、アクセス可能領域、記述の制限など。
グローバルデータサイズに制限有 小さい
MPIと同様のノードを意識したローカル記述
低速，コードが複雑，られているためである．図２は，この条件下で，各UPC (動的確保 upc_alloc)

28

28%

9.4 - 77.0

グローバルデータのサイズ、
アクセス制限なし

種言語の比較を行った．用いるスレッド数とノード数によっても各言語の性能が異なるため，この図では，ノード数を横軸に，各言語でもっとも最適だっ

2

XcalableMP

12

12%

1 - 1.2

SMint

4

5%

1

高速，グローバルデータのアクセス可能領域に制限あり
高速，グローバルデータのサイズ、アクセス制限なし

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書

種類のポインタ型が存在する．このため，型変換もCUDA コードを加えて，GPUDirect による GPU 間直接必要でプログラムの複雑になり，実行も低速になる．

通信を用いたプログラムも作成し評価している．評

これ以外に，UPC で大規模グローバルデータを扱う

価 に は ， 東 工 大 Tsubame3 （ InfiniBand ） と 東大には，UPC ローカル記述(表 1,2 行目）を利用するしReedbush-L（Omni-Path）を用い，異なる環境においかないが，これは，MPI と同様に，ノード内部はローても，SMS, OpenMP, OpenACC, CUDA を共存させカルデータとして記述，他ノードのデータはグローて，ユーザが利用するシステムのハードウエア環境

バルデータへアクセスというような別々の記述が必に応じた並列処理が可能であることを示した．

要となる．
(2) mSMS とマルチ GPU 処理方式の実装と性能調査

3D 27-point stencil temporal blocking (128 step, block size = 4)
(32GiB/node, 4 GPUs/node , Tsubame3.0)

１ノードに複数 GPU を持つシステムにおいて，Time [sec]mSMS を利用することで，ノード全体にグローバル
データを配置して，容易にマルチノードマルチ GPU処理が実現できることを示した[9]．
各ノードプロセス内の各CPUコアがGPUを使う

20.0
18.0
16.0
14.0
12.0
10.0
8.0
6.0
4.0
2.0
0.0

15.5

0

GPU GPU
1

2

コア1
コア0

GPU

17.3

17.3

18.2

18.5

18.8

スレッド間同期
ノード間同期ノード間袖領域転送(pre +overload)
bt毎CPU→GPU袖領域転送
bt毎GPU→CPU袖領域転送
その他
初回全領域転送(copyin)

1
GPU

16.7

PRELOAD / OVERLOAD 版

2

4

8

16

32

64

最終回全領域転送(copyout)

32GB 64GB 128GB 256GB 512GB 1TB

2TB

計算

3

ノード数 / 問題データサイズ(a) ホストメモリ経由の GPU データ交換

コア3
コア2

3D 27-point stencil temporal blocking (128 step, block size = 4)
(32GiB/node, 4 GPUs/node , Tsubame3.0)

Time [sec]大域アドレス空間

１ノードに複数GPUが搭載されてる場合の利用イメージ(a) マルチノードマルチ GPU システム

20.0
18.0
16.0
14.0
12.0
10.0
8.0
6.0
4.0
2.0
0.0

PRELOAD / OVERLOAD+ GPU Direct 版
スレッド間同期

16.5
13.6

14.4

14.6

14.9

15.2

ノード間同期ノード間袖領域転送(pre +overload)
bt毎GPU→GPU袖領域転送(gpudirect)
bt毎CPU→GPU袖領域転送

11.2

bt毎GPU→CPU袖領域転送
その他
初回全領域転送(copyin)

1

2

4

8

16

32

64

32GB 64GB 128GB 256GB 512GB 1TB 2TB
ノード数 / 問題データサイズ

最終回全領域転送(copyout)
計算(b) ノード内 GPU-Direct 利用時によるデータ交換
図 3 Tsubame3.0 27 点ステンシル実行時間

図 3 は，Tsubame3 における 27 点ステンシル計算（時間ブロッキング利用）の GPU 利用時の性能を示す．GPU ダイレクトを利用すると（図 3(b)），利用しない場合（図 3(a)）に比べ，ホスト－GPU 間のデータ転送コストが低減できる．１ノードに搭載す(b) SMS 関数 + OpenMP + OpenACC による記述
図 2 マルチノードマルチ GPU システムの利用例

る GPU のメモリ総量(Tsubame3: 4GPU x 16GB =64GB)にあわせて，各ノードの処理データ量を定め

図２に，想定するシステムと対応するプログラムている．１ノードの主メモリ（Tsubame3：256GB）の概要を示す.この例では，sms ライブラリ関数とを利用できるマルチ CPU コア処理に比べ，１ノー

OpenMP と OpenACC を利用している．文献[6]に記述

ドが担当する処理データ量は小規模になるため，はないが，１ノード内のマルチ GPU 処理において，CPU 利用時と同程度の問題サイズを GPU 処理する

ホスト-GPU 間のデータ通信を高速化するため，のであればより多くのノード台数が必要になる場

3

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書

合がある．

（3）不規則構造データとポインタ利用する応用の実装を可能にする mSMS
クラスタによる並列処理のうち，配列などの静的か
つ規則的データへの同期的処理では，各ノードが処

heap[0]

理するデータ領域が既知で事前にノードにデータ

heap[1]

heap[2]

heap[3](a) マルチノード向けグローバルツリーの実装を割り当て効率よく処理することができる．一方，元のBody

ツリーの生成やアクセスのように，不規則なデータ

処理順
①

②

③

④

⑤

この処理順だとツリーのアクセス
局所性 低Bodyからツリーを作成

構造をもち，実行時にアクセス先が決まる応用に対④

しては，事前にデータを分割して配置することは難

⑥

③ ⑤
②
４

1

⑥

しく，効率のよいアルゴリズムやプログラムの構築

2

は容易ではなく，大きなコストがかかる

6

この処理順だとツリーのアクセス
局所性 高

①
3

このような応用の一例として， N 体問題に広く用5近い順にBodyを書き換え

並び替えられたBody

いられている Barnes-Hut がある（図 4）．質点の位

④

②

③

⑤

⑥

①

処理順

置に対応したツリーを構築し，質点同士の力を計算(b)グローバルツリーのメモリアクセス局所性を高める BodySort 手の導入（Tree Traverse による）するが，一定の条件のもと，遠い距離にある質点群の計算はその重心で代替えして，計算を効率化する．

図５クラスタシステムにおけるｍSMS を利用した
グローバルツリーデータの効率的アクセス実装

26％に減少パラメタ θ
図4

θ ≧ s⁄d の時，重心で計算

Barnes-Hut アルゴリズムとツリーデータ構造

共有メモリシステムではポインタを用いたツリーへの再帰的アクセスにより Barnes-Hut は実装でき(a)質点当たりの 1 ステップ実行時間とメモリ使用量

るが，クラスタシステムでは，制限なしにポインタ

6％に減少を使ってグローバルツリーにアクセスする仕組みを提供するものはほとんどない．MPI では，グローバルツリーは実装できないため，必要なデータ（部分木）を各フェーズで計算してノードに転送して処理を進めるため，非常に複雑なコードになっている．
そこで今回，mSMS を利用して，OpenMP で実装した Barnes-Hut プログラムをほぼそのままの形で，(b)質点当たりの遠隔ノードデータのアクセス回数と実際のデータ転送回数（Pagereq）
図６ グローバルツリーへのアクセス局所性を高める
BodySort による性能向上(質点数：1280 万-40 億，４ノードｘ16 スレッド)

mSMS に変換して，性能を評価した[7]．同様の試み
は UPC でも行われているが，性能は非常に悪く，
しかも SMS と異なり，UPC には実行時ランタイム

4

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書

システムがないため，複数スレッドを制御する実行

そこで、mSMS の実応用例として、FDTD(2,4)法の制御コードもユーザが応用プログラムに埋め込む

マルチノード実装を行い、TSUBAME 3.0 及び ITO に必要もあり，コードが非常に複雑化している．

おいて性能評価を行った(研究業績[5])。

mSMS では，アクセス制限のない大規模なグロー

まず、袖領域の通信において、各計算に必要なデバルデータを，汎用の C ポインタで利用できるたータのプリフェッチ（SIGSEGV シグナルハンドラをめ，プログラムの改変はほとんどない．さらに，懸介さず、指定範囲のデータを cache ページとして取案であった遠隔データアクセスのためのオーバー得）を実現するプリロード API を利用した実装を行い、性能評価を行った。

40

Barnes-Hut N-body one step timeroot child create (θ=0.5) ( 64 Nodes x 32 threads)(1-node)Tree create(64-nodes)
Tree sort, store body(64-nodes)
Calculate force(64 nodes*32th)
move check(64 nodes)

Time (s)

30

20

10

0

ソルバーのウィークスケーリング性能の計測結果

2M

4M

8M

を示している。１ノードあたり 1024^3 の格子数を28.71持ち、ノード内並列化は OpenMP(各ノード 24 スレ
15.62

2.83 4.77
0.33 0.43 0.80 1.17 1.71
1M

図 8 は，
プリロード API を利用した並列 FDTD(2,4)

ッド)を利用した。TSUBAME 3.0 及び ITO における

8.61

１ノードの実行時間を基準とした実行時間比は 2-

16M 32M 64M 128M 256M 512M

32 ノードにおいて、1.09-1.30(TSUBAME 3.0)、
1.07-

Num of bodies

図７ 3 次元空間 N 体問題（質点数:1M－512M）

1.16(ITO)となった。TSUBAME 3.0 では主に同期時(Barnes-Hut, Oct-Tree,θ＝0.5，64 ｘ32 スレッド)間の増加による性能低下が確認されるが、ITO にお

ヘッドは，ツリーのアクセス局所性を高める

いては、ほぼ理想的な結果が得られたといえる。

BodySort（図 5）の導入により，非常に低減され，十分に実用に耐えることが明らかになった(図 6)．
文献[7]では，４分木を利用し，最大 16 ノードを利用した２次元空間を対象とする Barnes-Hut の例を提示したが，３次元空間を対象とし 64 ノードｘ
32 スレッド（2048 スレッド）利用による実装と評価も行っている（図７）．最大 819M 個の質点の 1
更新ステップあたり 45.5 秒，64M 個の質点では 5.8秒で処理できる．

図 8 Preload 機能を用いた Weak scaling 性能 [5]ｍSMS 利用により大規模なグローバルツリーをク

次に、実際的な計算で利用される複雑な境界条件

ラスタ上に構築し，汎用 C ポインタを利用し，共有を導入した際の、mSMS の有効性を調査した。実応用

メモリ向けのプログラムをほぼそのままで利用でにおいては、Berenger の PML 吸収境界条件や境界埋きることは，大きな利点である．しかも，利用できめ込み法の導入が一般的であるが、マルチノード並るグローバルデータは，ノード数×ノード当たりの列化を実現するには、袖領域等の通信の実装コスト

メモリサイズと，大規模な質点の処理が可能となる． が問題となる。上述の様に、mSMS ではプリロード API
を用いることにより通信の最適化が可能であるが、(4)音響解析 FDTD(2,4)計算の並列処理と性能評価

ユーザの目的によっては、明示的な通信を意識せず

音響数値解析手法の一種である音響 FDTD(2,4)に一定の性能が達成可能な、グローバルビューによ法は、通常の FDTD 法と比較して袖領域のステンシるプログラミングが有効となる場合が予想される。

ル読み込み幅が増加するが、空間方向に高次精度の

そこで、FDTD(2,4)法へ PML 境界条件を導入し、図 9計算が可能となるため、効率的な大規模音響解析にの様な実応用に近い計算条件での性能評価を行った。

向けたマルチノード並列化が求められている。

この場合、袖領域の通信は全て SEGV ハンドラを介し5

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書て行われ、プリロード API を用いた明示的な通信領

コア数やノード数を増大させることで計算基盤の域の設定は行っていない。

性能を向上させてきた．そうしたハードウェアを活用するためのソフトウェアも改良が続けられている．例えば，コンパイラによる自動 SIMD 化や，OpenMP による自動並列化などが実用化されている．
これら以外にも多くのソフトウェアが研究・開発され，マルチコア・プロセッサの性能を活用する基盤

図 9 ヘルムホルツ共鳴器モデル (PML 層数: 20, 格子として利用されている．

数: 1024^3). (b) 音圧分布 (time step: 5000). [5]

一方で問題となっているのが，分散メモリ型と呼図 10 に PML を導入した FDTD(2,4)法の各計算更新ばれるハードウェアの形態と，それを前提としたプ関数の ITO 上での平均実行時間を示す。通常の流体

ログラミングモデルの生産性である．分散メモリ型

ノードの更新(Update U, P)は上述のプリロード APIの並列計算機は，それぞれ独立したメモリを備えたを利用した場合と比べ、幾分の性能の低下は見られ計算ノードが，多数並列に動作する．そしてこのよるが、PML ノードの更新時間(Update PML U, P)は、

うなアーキテクチャを活用するためのプログラミ

ほぼ理想的な高速化が達成できている。

ングモデルが，MPI などの通信インターフェースである．このインターフェースを使用したソフトウェ
ア・システムでは，高性能なプログラムを実現するために，長い期間を費やして手動でチューニングする必要がある．本来アプリケーションプログラマは，
アルゴリズム自体の開発に注力するべきであり，個々のアプリケーションに特化したチューニング
作業からは解放されるべきであるが，このような開発形態は 20 数年間変わっていない．

図 10 PML を導入した FDTD(2,4)法の各計算関数の平そこで本研究では，PGAS をベースとした共有メ

均実行時間 [5]これらの結果より、FDTD(2,4)法の並列化におい

モリ型並列計算基盤に対して TM（トランザクショて mSMS の利用により良好な性能が得られ、実応用

ナルメモリ）の機能を提供し，これをコヒーレンス的なステンシル計算においても mSMS の利用が有効制御に活用することにより，生産性と性能を両立すである可能性が示された。ユーザの目的によって低る分散共有メモリ処理系の実現を目指す．マルチコ

い実装コストによる一定の性能の獲得から、明示的

アプロセッサ向けの TM をベースとして，分散用のな通信の実装による最適化まで幅広く選択が可能で機能を追加して拡張することでシステムを実現すあることは、数値解析を道具として用いる場合の研る．PGAS モデルのライブラリ実装である UPC++を

究サイクルを円滑に回す上で、非常に有用であると使用して分散共有メモリインターフェースおよび，

考えられる。

それに対する TM システムを設計・実装し，評価を行った．
赤黒木および K-Means の 2 つのマイクロベンチ(5)クラスタシステムにおけるトランザクショナル

マークにより評価を行った。

メモリ実行モデルの検討
現代の科学技術分野の進歩を支えている高性能

赤黒木では，ノード数を増やすことによる速度向

な大規模並列計算基盤は，その計算速度の向上のた上は確認できなかった(図 11)．赤黒木の性質から，めに，ハードウェア・ソフトウェア両面において多頻繁に要素を挿入すると，木のバランシングのため大な労力が費やされてきた．ハードウェア面では，に回転操作が発生する．すなわち，複数のメモリに6

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書

対して書き込みアクセスが発生するため，頻繁に競ンテンシブなプログラムである．これらのプログラ合が発生し，それに伴って性能が低下したと考えら

ムはシングル GPU 実行用に記述されたプログラムれる．しかし，軽微な変更だけで逐次プログラムかであることから，TSUBAME3.0 の全 2,160 台の GPU

ら分散並列プログラム用のデータ構造を定義でき，の中から無作為に 1 台の GPU を選択して上記プロ

それがノード数・スレッド数によらず正常に動作しグラムを実行し，実行中の消費電力を計測した．

た．この「分散並列プログラムが容易に記述でき，

なお，TSUBAME3.0 の GPU はすべて同一ファミリ

それが正常に動作する」という性質は，様々なアプ

ーの GPU（Tesla P100）であるが，後述するように，
各 GPU の消費電力にはばらつきが存在する．そこで計 100 台の GPU に対して上記の実験を行うことにより，TSUBAME3.0 における GPU の電力ばらつきの傾向を調査した．
GPU の消費電力は，ホスト側で nvidia-smi コマン
ドを実行することにより計測する．CUDA プログラ
ムの実行中に上記コマンドを 5ms 毎に実行し，GPU

赤黒木による評価

消費電力(最大値を1として正規化)

図 11

1
0.95
0.9
0.85
0.8
0.75
0.7
0.65
0.6
0.55
0

10

20

30

40

50

60

70

80

90

100

GPU ID

matrixMulCUBLAS

matrixMul

simpleMultiCopy

図 13 TSUBAME3.0 における GPU の電力ばらつき

図 12 K-Means による評価

使用率が 100%の時の消費電力の平均値を当該プロ

リケーションの特に開発初期段階において非常にグラムの消費電力とする．

重要である．

評価結果を図 13 に示す．グラフの横軸は（実験K-Means では，逐次実行した場合と比較していずに使用した）100 台の GPU の通し番号，縦軸は消費れの場合も速度向上していることを確認した(図電力である．各 GPU は，matrixMul を実行した際の12)．また，各ノードで実行するスレッド数によら消費電力の降順に通し番号を付与した．また，消費ず，ノード数の増大に伴って速度が向上しており，電力の値は，各プログラムにおいて最大の消費電力分散化することによる高速化を確認できた．

を示した GPU の消費電力で正規化してある．なお，
図の各点は，当該プログラムを当該 GPU で 50 回実(6) mSMS の省電力化方式の検討

行した時の消費電力の平均値である．

mSMS の省電力化方式を検討するための基礎デー

グラフより，GPU 電力のばらつきの大きさはプロタとして，TSUBAME3.0 において CUDA アプリケ

グラムによって異なることがわかる．特に，ーションを実行中の消費電力を測定した（研究業績

simpleMultiCopy では，GPU 間の消費電力の差が最大[8]）．測定には，CUDA SDK にサンプルプログラム

14.2%に達することが確認できた．また，同グラフとして内包されているプログラムの中から 3 つから，GPU 電力のばらつきの傾向はプログラムによ（matrixMul, matrixMulCUBLAS, simpleMultiCopy）って異なることがわかる．例えば，計算インテンシ

を選んで使用した．matrixMul と matrixMulCUBLAS

ブな matrixMul では 0 番の GPU が，メモリインテン

が計算インテンシブ，simpleMultiCopy がメモリイ

7

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書

シブな simpleMultiCopy では 31 番の GPU が最大電申請時に設定していた目標である、mSMS を用いた力を消費する．これは，GPU においてはコアとメモ

音響 FDTD 法のマルチノード並列プログラムの開発

リが別チップであり，それぞれが独立に製造ばらつ及び、実応用計算で利用される境界条件を含めたソきの影響を受けたためと考えられる．

ルバーの性能評価を予定通り実行し、FDTD(2,4)の並列化において mSMS が有効であることを示した。ま以上の結果より，mSMS の省電力化においては以下を考慮する必要があると考えられる．

た、追加目標として、FDTD(2,4)への時空間ブロッキ⚫ アプリケーションのメモリアクセス頻度に応じング手法(冗長計算有り)の導入を検討したが、袖領域たプロセス配置：プロセスの実行に最適な GPUの通信量の問題により、実装コストに見合う程の高はアプリケーションのメモリアクセス頻度によ速化は達成できていない。今後、冗長計算の無い時って異なると考えられる．

空間ブロッキング手法を導入することにより、さら⚫ プロセス間のデータ転送量に応じたプロセス配なる効率化が図れると考えられる。その他、mSMS+

置：データ転送量が多い程プロセスのメモリア

ノード内複数 GPU 利用や非同期プリロード API を

クセス頻度は高くなることから，メモリアクセ用いた計算と通信のオーバーラップなどが、今後のス頻度はアプリケーションだけでなくプロセス

展望である。以上の理由から、目標の達成率を 8 割

によっても異なると考えられる．

程度とする。
(5) クラスタシステムにおけるトランザクショナ

このため，GPU の消費電力を最小化の手法として，mSMS の機能を拡張し，アプリケーションやプロセ

ルメモリ実行モデルの検討

スごとのメモリアクセス頻度に応じて，各プロセス

PGAS をベースとした Intra-node 向け TM の設計おの GPU を割り当てる仕組みが必要と考えている．

よび実装について，そのプロトタイプ実装まで完了
し，複数のプログラムで正常に動作することを確認

今年度の進捗状況と今後の展望した。しかし，その性能がまだ十分でないことが評(1)-(3)の mSMS の API 実装と各種性能評価

価により確認された。特に，他ノードのメモリ上に6.

当初目標としていた内容の 90％程度達成できた

ある変数にトランザクション内でアクセスする際にと考えている．特に，(4)の音響解析の応用分野への発生する通信回数がボトルネックとなっていること

適用では，SMS 利用によりクラスタを利用して細かを確認した。以上のことから，今年度の進捗状況は 6

な境界条件の設定が非常にやりやすかったという割程度と判断する。

フィードバックを受け，さらに多くの応用分野の方

上記の性能問題は，キャッシュ機構を導入するこに利用して頂きたいと考えている．今年度，(5)(6)とで大きく削減できる可能性が高い．本研究で設計のテーマと十分な連携までには，いたらなかったが， した基盤にキャッシュ機構を検討中である．
マルチコアプロセッサを対象とした HTM では，キ(5)のクラスタにおける TM については，SMS を実装のサポートとして利用する方式が，今後考えられる． ャッシュコヒーレンスプロトコルに対して，新たに(6)の消費電力については，今年度，GPU 消費電力のSticky 状態と呼ばれるステートを追加することで，ばらつきを考慮したプロセス配置という一つの指TM の機能を実現している．しかし，ソフトウェアで針を得た．一方，一つの応用実行の観点からは，ユ実装する際に必ずしも踏襲すべき方法ではない．

ーザの求める速度性能・データの規模を考慮しつつ，

キャッシュの実装方法の一つに，Write-Invalidate

利用する GPU 数,CPU コア数,ノード数をどう選択す方式がある．しかしこの方式はトランザクション中

るかも消費電力低減になりうる．今後，消費電力設の書き込みが多い場合に invalidate が頻発する．

定に応じた柔軟なハードウエア選択を行うプログ

STAMP ベンチマークスイートのプログラムに含まラム実行も一つの手段と考えられる．

れるトランザクションの Read/Write 比を調べると，(4) 音響解析 FDTD(2,4)計算の並列処理と性能評価

Write の比率がかなり低いことが確認できる．
したが8

学際大規模情報基盤共同利用・共同研究拠点 2019 年度共同研究 最終報告書って，トランザクションでの書き込みは高い頻度で(3) 国際会議発表（査読あり）

発生しないと想定できる．これらの特徴をふまえた[5] Ryoya Tabata, Hiroko Midorikawa, Ki'nya Takahashi: "Performance
Evaluation of Acoustic FDTD(2,4) Method Using Distributed

キャッシュ方式の検討・実装が今後の課題である．

Shared Memory System mSMS", 2020 International Conference on
High Performance Computing in Asia-Pacific Region HPC Asia

(6) mSMS の省電力化方式の検討

2020 , pp.1-2 , Fukuoka, Japan, 2020.1

TSUBAME3.0 において GPU 電力の基礎データをAbstract:http://sighpc.ipsj.or.jp/HPCAsia2020/hpcasia2020_poster_

収集し，mSMS の省電力化方式の検討を行ったとい

abstracts/poster_abstract_52.pdf
Poster:http://sighpc.ipsj.or.jp/HPCAsia2020/hpcasia2020_posters/p

う点においては，計画書の目標を達成できた．しかoster_52.pdf(4) 国内会議発表

しながら，当初の計画とは異なり，実際に mSMS を（査読なし、査読あり）[6] 阪口裕悟，緑川博子:"グローバルビュープログラミングをサポートする PGAS 言語の記述性と性能の比較", 情報処理学会，
研究報告ハイパフォーマンスコンピューティングに mSMS の省電力化方式を検討するには至らなか（HPC）,Vol.2019-HPC-170, No.41,pp.1-8, （July 2019）
った点はマイナスである．これは CUDA+mSMS，[7] 緑 川 博 子 , 柴 山 悠 :" 分 散 共 有 メ モ リ シ ス テ ム を 利 用 し た
Barnes-Hut アルゴリズムの初期並列実装と性能評価", 情報
OpenACC+mSMS のアプリケーション開発が間に合処理学会，研究報告ハイパフォーマンスコンピューティング（HPC）,Vol.2019-HPC-170, No.43,pp.1-8, (July 2019）
わなかったためである．また，当初の計画では，CPU[8] 大八木哲哉，浅田 風太，三輪 忍，八巻 隼人，本多 弘樹："TSUBAME3.0 における製造ばらつきを考慮した GPU の電力モ
やメモリの消費電力も計測する予定であったが，計
デリングの高速化"， 情報処理学会，研究報告ハイパフォー
測に必要なツール（RAPL）の使用許可が下りなかっマンスコンピューティング（HPC）,Vol.2019-HPC-172, No.24,
pp.1-8, (Dec. 2019)
たため，GPU 電力のみにフォーカスせざるを得なか[9] 阪口裕悟，緑川博子:"マルチノード・マルチ GPU プログラミ
ングを容易にする分散共有メモリシステム", 情報処理学会，った．以上から，今年度の進捗は 6 割程度である．
研究報告ハイパフォーマンスコンピューティング（HPC）,Vol.2020-HPC-173,No.7,pp.1-8, (March 2020)
今後の課題としては，mSMS を使用するアプリケ[10] 小林 龍之介, 二間瀬 悠希, 塩谷 亮太, 五島 正裕, 津邑 公ーションの消費電力評価，および，上記アプリケー
暁: “メモリアクセス解析に基づくトランザクショナルメモリの ポ リ シ ー 動 的 切 り 替 え 手 法 ”, 情 処 研 報 (HotSPA2019),
ションを実行中の CPU とメモリの消費電力の測定
Vol.2019-ARC-236, No.25, pp.1–11 (May. 2019)[11] 川口 優樹, 津邑 公暁: “メモリアクセスパターンに基づくが挙げられる．
GPU ス ケ ジ ュ ー リ ン グ ポ リ シ ー の 選 択 手 法 ”, 情 処 研 報(HotSPA2019), Vol.2019-ARC-236, No.2, pp.1–9 (May. 2019)[12] （査読あり）小林 龍之介, 二間瀬 悠希, 多治見 知紀, 塩谷7. 研究業績一覧（発表予定も含む）
亮太, 五島 正裕, 津邑 公暁, “トランザクショナルメモリにおけるメモリアクセスパターンを考慮したポリシー動的切り(1) 学術論文 （査読あり）
替 え手法 ”, The 3rd cross-disciplinary Workshop on Computing
Systems, Infrastructures, and Programming (xSIG 2019), Bestなし
Undergraduate Student Award 受賞[13] 川口 優樹, 津邑 公暁: “静的解析に基づく GPU スケジューリ(2) 会議プロシーディングス （査読あり）
ングポリシーの選択手法”, The 3rd cross-disciplinary Workshop[1] Y. Sakaguchi, H. Midorikawa: "The Programability andon Computing Systems, Infrastructures, and Programming (xSIG
Performance of Global-View Programming API: SMint for Multi2019), Outstanding Effort Award 受賞
node and Multi-core Processing", 2019 IEEE Pacific Rim [14] （査読あり）飯田 凌大, 塩谷 亮太, 五島 正裕, 津邑 公暁，”
一貫性検証手法の動的切り替えによるソフトウェアトランザ
Conference on Communications, Computers and Signal Processing,ク シ ョ ナ ル メ モ リ の 高 速 化 ”, The 3rd cross-disciplinary
DOI: 10.1109/PACRIM47961.2019.8985126 pp.1-8, 2019.8
Workshop on Computing Systems, Infrastructures, and[2] H. Midorikawa, K. Kitagawa, Y. Sakaguchi: "mSMS : PGAS
Programming (xSIG 2019), Outstanding M1 Student Award 受賞
Runtime with Efficient Thread-based Communication for Global- [15] 浅井 優太, 山下 淳, 小林 龍之介, 二間瀬 悠希, 塩谷 亮太,
view Programming", 2019 IEEE International Conference on Cluster
五島 正裕, 津邑 公暁, “ハードウェア機構の活用によるハイブリッドトランザクショナルメモリ高速化の検討”, 情処研報
Computing (Cluster2019), DOI: 10.1109/CLUSTER.2019.8891009,(ETNET2020), Vol.2020-ARC-240, No.34, pp.1–11 (Feb. 2020)
pp.1-2, 2019.9[16] 山下 淳, 浅井 優太, 小林 龍之介, 二間瀬 悠希, 塩谷 亮太,[3] R. Tabata, T. Kobayashi, K. Takahashi, ‘Numerical study of
五島 正裕, 津邑 公暁, “グラフ処理を題材とした最適なトラン ザクショ ナルメモ リプログ ラミン グの 検討 ”, 情処研 報Synchronization Phenomena of an Air-Jet Instrument using Finite(ETNET2020), Vol.2020-ARC-240, No.7, pp.1–10 (Feb. 2020), 電Difference Lattice Boltzmann Method’, International Symposium on
子情報通信学会 コンピュータシステム研究会 優秀若手発表
Music Acoustics (ISMA), pp.296-303, Detmold Germany, Sep. 2019.9
賞 受賞
http://pub.dega-akustik.de/ISMA2019/data/articles/000020.pdf

使用するアプリケーションの消費電力データを元[4] Y.Inouchi, H.Yamaki, S.Miwa, T.Tsumura: “Functionally-Predefined(5) その他（特許，プレスリリース，著書等）

Kernel: a Way to Reduce CNN computation”, Proc. IEEE Pacificなし

Rim Conf. on Communications, Computers and Signal Processing(PacRim 2019), 6p, 2019.9, received Best Paper Award for
Computers Track (1/27 = 3.7%)

9