情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31

ソフトウエア分散共有メモリシステム mSMS による大規模マルチ
コアノードにおけるステンシル計算
緑川 博子†1


概要：筆者らは，マルチノードに分散マップされた大規模ブローバルデータを提供し，マルチノードマルチ
スレッド並列による効率的な処理が可能で，生産性の高いプログラミング環境を提供するソフトウエア分散共
有メモリ mSMS を構築している．これまで 72 ノードまでのクラスタシステムにおいて，ノード当たり 24-52 ス
レッドを用いて，3 種のステンシル計算アルゴリズムを実装し，MPI プログラムとの性能比較を行った．この結果，各ノードに同一の大規模共有アドレス空間を提供しつつ，ステンシル計算では MPI と比較しても十分高速な性能で処理できることを示した．本報告では，さらに大規模なシステム（180 ノード）における，性能調査を行った．この結果，180 ノード利用で，約 23TB の大規模データを各ノードプロセスへ提供し，ポインタを含む共有メモリモデルによるプログラミング環境を実現した．また，大規模ノード特有の問題点や，MPI 実装の影響などを明らかにした．

キーワード：ソフトウエア分散共有メモリ，PGAS，マルチノードマルチスレッドプログラム，MPI，大規模メモリ，
共有メモリプログラミングモデル，マルチスレッド

1. はじめにも可能とするシステムはほとんどない．
このような視点から，筆者らは，古典的ページベースの高性能計算応用においては，高速ネットワークで結ばれソフトウエア分散共有メモリ（SDSM）に，以下のような機た複数計算ノードとノード内マルチコア（あるいは GPU な能を新たに導入した mSMS を構築し，クラスタの各ノード

ど の ア ク セ ラ レ ー タ ） を 有 効 利 用 す る た め ， MPI ＋ X

プロセスに同一共有アドレス空間を提供し，ノード内マル（OpenMP，OpenACC など）によるプログラミング手法がチコアプログラミングと，ノード間マルチノードプログラ

広く用いられている．また，分散メモリモデルである MPI

ミングをシームレスに行うプログラミング環境を実現した．

によるプログラムの書きにくさ，プログラム開発の生産性の低さを改善するために，PGAS（Partitioned Global Address

動的に生成・消滅する複数のユーザスレッドからのSpace）モデルで総称される様々な言語や API などが提案

非同期・範囲無制限の遠隔データアクセスに対応．

されている[9]． 現在，PGAS として，大域的データのグロ（マルチノード＋pthread，OpenMP，OpenACC，Cuda）

ーバルビューを提供しながらデータの所在に考慮した様々なシステムが登場し，一定レベル以上の性能と MPI よりも高いプログラム生産性，あるいは，新しい並列実行モデ

レッドによる送受信通信機構
ルの提供，もしくは特定応用向けに高性能化など，様々な名称になっている．多くの PGAS では，MPI と異なり，大域

予めデータアクセス範囲が予測可能な時，計算（アクセス）前に大域データをまとめてローカルにフェ方向への研究が行われている．このため，PGAS とは，事実上，多種多様な実行モデルとシステム，言語を包含する計算ノード間のページ送受信を高速化するマルチス

ッチする preload 機構


マルチノード間の実行同期，通信低減型データ一貫性同期の提供データ配列宣言や大域インデックスを利用できることでグ
ローバルビューを謳っているが，各ノードプロセスがアクmSMS では，図 1 に示すように，マルチノードマルチス

セスできる遠隔データの範囲に制限があったり，遠隔デー

レッドシステムにおいて，各ノードの物理メモリサイズとタ利用前に事前にアクセス領域の宣言が必要である場合もノード数に応じた大規模大域データを定義でき，各ノードある．遠隔データアクセス API においても，データの所在において，各データ部分をスレッド並列で処理することが（ノード番号など）を付してデータにアクセスする，あるできる．大域データは，任意のノードへの非対称な割り付

いは MPI 片側通信のような API などを必要とする場合もあけも可能である．大域データのアクセスに制限はないが，る．多くの場合，真の同一共有メモリアドレス空間を提供

ローカルメモリアクセスを高めるように，ユーザがデータしておらず，特定のコンパイラを介して，上記の API を下割り付けを自由に決めることができる．mSMS は，現在，層通信実装の関数（MPI など）に変換している．すなわち，MPI を下層通信に用い，ユーザレベルソフトウエアで実装

全ノードプロセスが，同一のアドレス空間を共有して，C 言されているため，管理者権限は不要で誰でも容易に利用可

語のポインタ変数やアドレスを使ったアクセスを行うこと能である.

†1 成蹊大学

Seikei University.

ⓒ 2018 Information Processing Society of Japan1

情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31

とも可能である．
MPI と同様に，用いる計算ノード名を列挙したマシンフ
ァイルと，利用可能な物理メモリ総容量，ローカルページとキャッシュページ，作業領域の各サイズ割合などを指定した mSMS メモリ構成ファイルを実行時に指定する．

int main( )mallocを変更するだけ{
遠隔メモリを利用可能
sms_startup(&argc, &argv);
array = (int*) sms_alloc(sizeof(int) * N, node);または 以下の分散マップ

array = (int*) sms_mapalloc( dim, div, ..…);
図1

if (sms_pid ==0 ){// node別記述も可能#pragma omp parallel forfor ( i = 0; i < N; i++ ) {array[i] = i; .... マルチスレッド処理}}
OpenMP, pthread:
利用可能
sms_shutdown();}

マルチノードマルチスレッド共有メモリプログラミ
ングのイメージ

2. mSMS の概要
2.1 mSMS におけるプログラム
mSMS を利用するプログラムは，MPI と同様に SMS ライ

動的データ確保する mSMS プログラム

図 2 (a)ブラリ関数のみを用いて図 2(a)のように C で作成する．あるいは，MpC トランスレータを用い，図 2(b)のように大域データをデータ分散マッピング指定付き多次元配列宣言で利用することもできる[2]．いずれのプログラムでも，スレッド実装された既存の汎用数学ライブラリ関数や，OpenMP,
OpenACC，pthread 関数などを，各ノード処理部分にそのまshared int a[NZ][NY][NX]::[NPROCS][1][1](0,NPROCS);
int main (int argc, char *argv[]){
配列宣言による
int i, j, k;
遠隔メモリ利用も可能
int size = NZ / NPROCS;//各ノードのアクセス範囲を計算 st - enint st = MYPID * size, en = (MYPID+1)*size;
mpc_init ();#pragma omp parallel forfor ( i = st; i< en; i++) { // st – en 範囲
for ( j = 0; j < NY; j++)for ( k = 0; k < NX; k++)a[i][j][k] = .... マルチスレッド処理}
mpc_barrier();
mpc_exit();

ま使用できる．
ユーザプログラムは MPI と同様に各ノードでプロセスとして実行され，sms_alloc，sms_mapalloc などで確保された大域データは各ノードから見て同一アドレス空間上に確保され，グローバルビューを提供するだけでなく，どのノードからもアクセス可能である．このため，アドレスポイ}

ンタを用いる C プログラムにもシームレスに対応でき，既存のプログラムを容易に移植できる．

図 2 (b)

MpC トランスレータ利用 mSMS プログラム

2.2 mSMS における大域データと SMS ページ
ローカルノードにないデータにユーザプログラムスレッドがアクセスすると，SEGV ハンドラが起動し，該当ページを持つ遠隔ノードからページを取得し，図 3 のように，キャッシュページ領域として確保されたローカル物理メモ
リ上に取得し，ローカルノードの大域アドレス空間上にア
クセス可能領域としてマップされる．
大域データ送受信の単位（ページサイズ）は SMS 独自のページサイズ(OS のページサイズの倍数)で行い，SMS ペー
ジ表により，どのページをどのノードが保持しているかを管理している．SMS ページサイズは，応用のデータアクセ

図 3mSMS における大域データ分散例

ス特性に応じて，プログラム実行時にユーザが指定するこⓒ 2018 Information Processing Society of Japan2

情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31

ノードに要求メッセージを送信し，担当ノード内で中心的
2.3 マルチスレッドによる大域データへの非同期アクセ

な管理制御を行う．一方，他ノードへ要求したページの受スの実現

信や，他ノードからのページ要求など，外からのメッセー

mSMS では，多くの PGAS 基盤システムのように，GET

ジ受信は，すべて受信スレッド（Rec）が行う．受け取ったや PUT といったユーザが明示的に指定した時のみにデー

メッセージの内，通信スレッドによる処理が必要な場合にタを取得できる，あるいは，大域データアクセス範囲に制は，受信キュー（Rec. Que.）に要求を入れて通信スレッド限を設ける，などを行っていない．このため，ユーザプロに処理に任せる．他ノードからの返値などがある時は，返グラムを構成する複数スレッドから非同期にページ要求が値キュー（Ret. Que.）に格納する．一方，非同期に送られ生成される．これに対応し，ユーザに一貫性のあるデータてくる他ノードからのページ要求は，ページキュー（Pageを提供するため，遠隔ノードから受け取ったページをユーQue.）に入れて，ページ送信専用スレッド（Send）に処理

ザプログラムのアドレス空間に張り付ける瞬間は，ページを任せる．

要求スレッド以外の実行中の全ユーザスレッドを一時的に通信には，古典的で単純な MPI 両側通信のみを用いていサスペンドする機構を用いている．この手法は，out-of-core

る．理由は，MPI の内部実装レベルの差や制限などの影響処理のため，複数の遠隔ノードメモリを利用する分散大容を受けにくく安定している，また片側通信と異なり，アク量メモリシステム m-DLM [4-6]において開発した機構をベ

セス可能データ範囲制約がないからである．MPI スレッド

ースにし，改良を加えている．ユーザスレッドの一時的なサポートレベルは，最高位の Multiple を利用している．一

サスペンドは，オーバーヘッドが高いのではと当初危惧し

般に，Multiple 設定での複数スレッド通信は，単一スレッ

たが，実際に調べてみると，遠隔ページへのアクセスが非ド（プロセス）通信よりも低性能と言われているが，機能常に高い状況では，多くのスレッドが自分の要求したペー

別に設計された限られた数の通信スレッドが同時に処理をジのフェッチ待ちになっていること，遠隔ページへのアク行うことにより，単一スレッドによる通信に比べ，効率的セスが低い場合には，ページフェッチの機会が減り，サスな通信が行われている．いずれの通信スレッドも，通信効

ペンドの機会が限られることなどから，実際には，サスペ率の良いコアにそれぞれバインディングしている．コアバ

ンドの影響は，実用に耐えうるレベルであることがわかっ

インディングは，通信性能に大きな向上をもたらすことが，ている[6].

わかっている．

この機構を実現するには，pthread や OpenMP プログラム
において動的に生成・消滅するスレッドに対し，現在実行中のユーザスレッドを正確に捕捉し，サスペンド・解除シ
グ ナ ル を 送 る 必 要 が ある ． スレ ッ ド生 成 につ い て は ，pthread_create を hook することで正確に捕捉できるが，ス
レッド終了については，pthread_exit を呼ぶとは限らない上，存在しないスレッドへのシグナル送信時に pthread_kill 関数が返すはずの失敗の返値が実現されていない Linux 実装に対処するため，現在は/proc 下の情報を用いて pthread のスレッド ID と Linux のプロセス ID を関連づけて，動的に生成，消滅するユーザスレッドの変動に対処している．
2.4 複数通信スレッドによるノード間通信の実現
mSMS では，図 4 に示すように，3 つの SMS システムス

Node

Node
Ut

Cal.
Que.

Com

Com

Cal.
Que.
Ret.
Que.

Ut

Ret.
Que.

:

Rec.
Que.

Rec

Rec

Rec.
Que.

Page
Que.

Send

Send

Page
Que.

Ut

Ut
*Ut
*
:
Ut

User Application threads
User Application threads
Ut: User thread, Com, Rec, Send : System threads

図4

ＭSMS の内部実装

2.5 遠隔ノードからのページ取得プロトコル

レッドを内部で用いている．ユーザプログラムが，初期化

ここでは，遠隔ノードからページ取得機構について述べ関数 sms_startup を呼ぶと，自動的に SMS システムスレッ

る．遠隔ノードとのページ「交換」プロトコル・通信手法

ドが生成され，各種システムデータの初期化が各ノードでに関しては，Multi-SMS[3]や，m-DLM [5,7,8]において数十行われる．

のマルチスレッド通信実装方式の性能調査を行ってきた．

mSMS では，ユーザスレッドからの様々な処理要求（メmSMS の現実装では，m-DLM と異なり，遠隔ノードとのペ

モリ割りつけ，ページ要求，終了処理など）は，図 4 の計ージの交換（swap）は行わず，cache 領域への遠隔ページ取算キュー（Cal. Que.）に登録され，起動時に自動生成され得のみを行う．m-DLM では，最も効率が良いと思われるプ

た通信スレッド（Com）が計算キューから各ユーザスレッ

ロトコルが用いた MPI 内部実装の制限（バグ？）により，ドの要求を取り出し，順次，処理する．通信スレッドは，

実 現 で き な い 場 合 が あ っ た が ， swap-out を 行 わ な い 現

ユーザプログラムからの様々な要求に応じ，該当する遠隔ⓒ 2018 Information Processing Society of Japan3

情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31

mSMS では，安定かつ高効率のプロトコルの実装が可能でを，ユーザデータ領域に直接，受け取る．

あった．

(8) 受信スレッドが，(6)で一時停止させたユーザスレッド

ユーザプログラム中の１スレッドが，ローカルノードにを再開させる．

ないデータへアクセスしてから，SEGV シグナルハンドラ(9) 受信スレッドが, SEGV ハンドラ内で要求ページを待っ内で，他ノードから該当ページ取得，貼り付けを完了し，ているユーザスレッドを起こす

該当ユーザスレッドの実行再開までの，手順を以下に示す．

(10) 受信スレッドが，受け取ったページと同じページを要

図 5 はページ要求送信ノードでの処理，図 6 はページ要求

求していて SEGV ハンドラ内でページを待つユーザスレッ

受信ノードでの処理を示す．

ドがあるか調べる．
(11)もし，待っているスレッドがある場合には，このスレッSegv – Send Page Req – Recv Page protocol in MSMS (r91)
Node

Node
User Program(2) page‐req
is queued(1’) accessremotepage data

thread‐1(1) accessremotepage data::

DLM system(3) pick up(dequeued)(11) inform
Otherssegv handler

Cal_Que::(9) informfinished

Rec_Que(7) page apply(6)suspend
all threads

thread‐nCom‐threadRec‐thread(5) receive
page header

Send‐
threadRet_Quethread‐k(10) CheckothersUser‐thread action

Send‐
threadmSMS では，データ一貫性管理を単純化するため，同期型データ一貫性保持（weak consistency model）のみを現在
やすほど利用できる大域データのサイズを大きくできるよ

Rec‐thread

Page_Que

2.6 実行同期とデータ一貫性同期は実装している．図 1，図 3 に示すように，ノード数を増(7) receivepage(8) restart
all threads

ドを起こす．

(4) send page‐
req msg

Com‐thread action
Rec‐thread action

うに，各ノードが大域データを分担して owner ページとして保持し，他ノードからの cache ページと区別する．デー
タ一貫性同期時に，（１）各ノードの cache ページ変更部分

図5

送信ノード：ユーザスレッドのページ要求処理プロトコルれる（sms_barrier），あるいは，（２）cache ページに変更がRecv Page Req – Send Page protocol in MSMS (r91)
NodeUser Program

thread‐1Com‐thread(3) insert
page req::

Page_que(4) pickup
page req

Rec‐thread

Rec‐thread(5) send
headerにする）．一方，データ一貫性制御はおこなわず，cache ページを保持したまま実行同期のみ行うこともできる(6) send page
Send‐
threadれも，cache ページは捨てられる（該当アドレスページ領域
はアクセス不可に設定され，次回以降に segv が起こるよう(1) receive
page req
Recv_quethread‐k

あってもそのまま cache ページを破棄し，大域データに反映しない(sms_sync_drop)，の 2 種を更新方式がある．いずCom‐threadreturn_val::

thread‐nNode

DLM system
Calc_queをそのページの owner ノードに伝え，大域データに反映さ(sms_sync)．

Rec‐thread action
Send‐thread action

2.7 大域データの事前フェッチ：preload
図6

受信ノード：他ノードからのページ要求処理プロトコル

mSMS では，通常，ユーザスレッドが実行中にローカルにない大域データにアクセスしてから，遠隔ノードからの遠隔ページ取得手順

ページ取得が行われるため，当該スレッドが計算を一時中(1) ユーザスレッドがローカルメモリにないデータをア断してデータの到着を待つ遅延時間が生じる，また，当該クセスすると Segv シグナルハンドラが起動される．

ページをアドレス空間に張り付ける瞬間にも，データ一貫(2) ユーザスレッドはハンドラ内で Cal キューにページ要性保持のため，その他のユーザスレッドの実行も一時的に求を登録して，ページを待つ．

サスペンドされる．しかし，多くの応用で，配列データを(3) 通信スレッドが，Cal 要求キューからページ要求を取り小規模のブロックに分割して処理を進める場合など，あら出す．

かじめ，アクセスするデータ範囲が計算前にわかっている(4) 通信スレッドが SMS ページ表を見て，該当ページを持場合も多い．このような応用処理パターンに対し，計算開つ遠隔ノードにページ要求を送信．

始前にあらかじめアクセスする領域を，SIGSEGV シグナル(5) ページ要求を受け取った遠隔ノードは該当するページ

ハンドラを介さずに，事前フェッチを行う関数を取り出し，メッセージヘッダーとページ本体を要求元ノ

sms_preload_array，sms_preload を用意している．いずれのードへ送る．受信ノードの受信スレッドは，メッセージヘ

関 数 も ア ク セ ス 前 に 指 定 し た 範 囲 の ペ ー ジ を ま とめ てッダーのみを受け取る．

cache ページとして取得する．通常のページフェッチでは，(6) 受信スレッドが，ユーザプログラムから起動された実SEGV を起こしたアドレスを含む当該ページ 1 枚をフェッ

行中の全てのユーザスレッドを一時停止させる．

チするだけであるが， sms_preload は，大域データの開始(7) 受信スレッドは，メモリサーバからの送られたページ

アドレスから指定サイズの連続ページを一度で転送する．

ⓒ 2018 Information Processing Society of Japan4

情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31

sms_preload_array では，大域配列データの中から，任意の3.1 ステンシル計算アルゴリズム

次元サイズの部分配列データの取得が可能で，関数内部で，用いたステンシルアルゴリズムは，（１）毎時間ステップ

指定データ範囲のアドレス連続性を調べ，連続ページはま

毎 ， 隣 接 ノ ー ド と デ ー タ 交 換 を 行 う ア ル ゴ リ ズ ム A1

とめて転送する．指定範囲にあるデータが owner ページに

（simple-stencil）と，（２）ノード間の通信回数を減らすた

ある，あるいはすでにローカルにフェッチされている場合

めの時間ブロッキング（全体時間ステップ 128，時間ブロには実際の転送を行わない．さらに関数引数で read か write

ックサイズ 16）を用いて，時間ブロックステップ毎のデー

かをあらかじめ指定できるため，同じデータをリードしてタ交換にしたもので行った．時間ブロッキングでは，冗長からライトするなど，SEGV ハンドラ経由では，2 回のメモ計算が生じるアルゴリズム A2 (redundant-stencil）と，冗長

リアクセス属性変更が必要な場合でも，一度でアクセス属

計算を省くために内部を 2 フェーズの処理の分けた冗長計性設定ができる．

算のないアルゴリズム A3（no-redundant-stencil）を実装し，また，read はせずに write のみ行う領域については，遠隔

合計 3 種類のアルゴリズムを用いた．

ノードから実際のデータ領域転送はせずに，指定範囲のペ

また，各アルゴリズムに対し，前述の preload を利用しージをリードライト可能と設定するのみ．あるいは，すでて，計算前に事前に隣接ノードからの一括データフェッチにキャッシュされているページに対し，上書き書き込みをを行うものと，計算時のアクセス時の segv ハンドラ経由でする overload 関数など，幾つかのユーティリティを設計，の遠隔ページフェッチを行うものの 2 種（例

実装中である．

を調査した．

3. 大規模クラスタおける mSMS によるステン
シル計算

計算量の多い近傍 27 点ステンシルと計算量の少ない近傍

すでに，mSMS の初期性能評価実験として，72 ノードまいる 1 ノード内で用いる適切なスレッド数（OpenMP 利用

A1 と A1p）

ステンシル計算としては，同じデータアクセスに対し，
7 点ステンシル計算の 2 種を行った． それぞれの計算で用での TSUBAME3 [10,11] を用い，典型的な計算カーネルの時）を 4 ノードによる並列処理で事前調査した．この結果，一つとして，3 次元配列のステンシル計算のマルチノード

図７に示すように，それぞれ性能が飽和し始めるスレッド

マルチスレッド並列処理を行った[12]．今回は，Taubame3.0

数として，7 点ステンシルでは 24 スレッド，27 点ステンシの全体ノード数（540）の 1/3 にあたる 180 ノードを利用し

ル 52 スレッドを用いた．ここでは紙面の制約から，7 点スて，さらに大規模なクラスタにおける mSMS の稼働・性能

テンシルの結果のみを示す．

の 調 査 を 行 っ た ． Tsubame3.0 の ノ ー ド 間 接 続 は ， IntelOmni-path（HFI100Gbps x 4）で，1 ノードに 4 GPU と 2 CPU250( E5-2680 v4, 2.4 GHz, 14 cores / 28 threads)を有する．今回の200

実験では，ノード内の 2CPU を OpenMP で利用する．

列の部分ブロックとして割り当てることとし，ノード当たり（bx, by, bz）= (4096, 2048, 1024) のブロックを割り当て，

域を，プロセッサの L2,

L3 キャッシュサイズを意識した小ブロックにさらに分割し，OpenMP を用いマルチスレッ
ド処理している．実行には，１ノードをすべて占有にして実行しており，CPU 処理に他の job の影響を受けないようにしているが，72 ノード利用時より，同じプログラムでも，
TSUBAME3 では，job 実行毎に性能がばらつくことがある．
さらに，今回の実験では，128 ノード以上の多数ノード
における intel-MPI の動作が安定せず（128 ノード未満と実装形態が異なるため），多数ノードになると，MPI 起動時のノード間接続にリトライが何度も繰り返される，規定時間内に通信が確立せずに，エラー終了する，MPI 起動時にサスペンドして，アプリプログラムが実行できないまま，job
が終了するなどの様々な状況が発生した．

ⓒ 2018 Information Processing Society of Japan

Gflops159

27‐point Gflops

150

139 144
124

106
100

50

全体として，大域データ配列を z 方向に分割する単純な分割方式とした．各ノードでは，担当するブロックデータ領

176 182

7‐point Gflops

TSUBAME3 は，1 ノードあたり，256GiB の主メモリを持つが，そのうちの半分（128GB）を，問題全体の 3 次元配27‐point & 7‐point Simple Stencil Performance
512GiB‐Problem (4K x 2K x 2K x2 x double precision)
217
4‐node of Tsubame3.0
201
200 199

85
59
45 50

50

52 54

8

16

20

57

56

57 56

57

24 28 32 36
Num of Threads

40

44

52

54 56

56

30
15 24
12

0
2

4

12

48

56

図 7 ４ノード mSMS 利用時単純ステンシル性能
3.2 単純ステンシル計算（空間ブロッキング）A1 の性能
図 8(a)(b)に 2 ノード（256GiB 問題）から 180 ノード（23TiB 問題）までの単純ステンシル A1 の実行時間と性能を示す．各ノードの担当データ領域の両側の袖領域のデー
タを通常の sigsegv によ りフェッチした場合（A1）と
sms_preload_array 関 数 を 用 い て 事 前 フ ェ ッ チ し た 場 合(A1p)を示す．性能，実行時間ともに，多数ノードになるに従い，preload 利用の効果が大きくなる．図 8(c)(d)は，segvと preload の各方式で rank0 における総実行時間の処理成分を示す．Segv 方式の計算時間（Cal）には，segv による5

情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31

Time(sec)

1000
884 908 919
900
797
778
769
737
800
714
687 707660 700700
602 604 642
531 637
600 509 523 528 556 564
500
400
300
200
100
0
2
4
8
16
32
64
72
96 128 160 180
Num of nodes

図 8 (a)mSMS 単純ステンシル計算 (segv)

実行時間

1000
857 858855
900
800
611 610590 606700
528 556 556 593
594 590 615 620 617
600 518 557 540 544 550 557
500
400
300
200
100
0
2
4
8
16
32
64
72
96 128 160 180
Num of nodes

図 9 (a)mSMS 時間ブロッキングステンシル計算

2566

3000

3000
2011

2000

1706
1316

1500

1059
935 1048
814
732

1000

2219

1550

GFLOPS(No preload)

1274

1500

0

2

4

図 8 (b)

8

16

500

128

160

mSMS 単純ステンシル計算 (preload)

性能

Cal (segv)

32
64
72
Num of nodes

96

176

127
600

267

200 2312180

図 9 (b)929 1037

512477
259
130
237
126

273 292816

Cal (segv)

800

350 374 382

23

4

32
64
72
Num of nodes

96

128

160

mSMS 時間ブロッキングステンシル計算

1000

400
200

1846

1642

1317

180

性能

no preload (segv) time component (sec) rank‐0
Redundant‐7pTime(s)800

Barrier

34 33 63 63

14301385
1066

0

no preload(segv) time component (sec) rank‐0
simple‐7p
1000

1011

1000

499
253 199 382
35 33 67 55 133102

500

1831

2000

1724

GFlopsGFLOPS(No preload)

2269

GFLOPS(preload)

2500

GFLOPS(preload)

2500

GFlops

実行時間

Redundant 7p stencil Performance GFLOPS (nt=128)

Simple 7p stencil Performance GFLOPS (nt=128)

Time(s)alltime(s) preload
alltime(s) no preload

Redundant 7p stencil Time
(128GB/node, 24 threads, nt=128)

Time(sec)

alltime(s) preload
alltime(s) no preload

Simple 7p stencil Time
(128GB/node, 24 threads, nt=128)

600

45

143
75

57 73

142 145

92 88

400
200

508 510 512 507 506 502 505 505 534 534 537

22

3Barrier

712 715 713
525 534 511 536 517 532 519 522

0
0

2
2

図 8 (c)4816 32 64 72
Num of nodes

96

4

8

128 160 180

図 9 (c)

単純ステンシル preload なし(segv)

16 32 64 72
Num of nodes

96

128 160 180

時間ブロッキングステンシル preload なし

時間成分

時間成分

preload time component(sec) rank‐0 Redundant‐7p
preload time component(sec) rank‐0 simple‐7p
1000
1000
preloadBarrier

Time (s)

800
600

10

24
2

31

68

69

102
2

105
2

146 1505

188 203

11

10

400

1

200

498 497 495 484 493 498 498 493 504 500 500

2

3

2

3

Cal

preloadBarrier

7

27

34

78

30

24

9

9

9

9

9

800
Time (s)

Cal

600

8

400

7

200

9

86

95

98

99

8

13

12

13

503 541 502 511 513 514 507 497 507 511 505

002

図 8(d)

4

8

16

32
64
72
Num of nodes

96

単純ステンシル preload あり

2

128 160 180

時間成分

図 9 (d)

4

8

16

32
64
72
Num of nodes

96

128 160 180

時間ブロッキングステンシル preload あり

時間成分

オーバーヘッドが含まれる．preload 方式では，Cal 時間ののデータ更新，データのフェッチがある．Preload 方式では，

他に preload 時間が示されている．

計算時間が segv 方式に対し 2-7%程度高速化されているが，単純ステンシル計算では，全体で 128 回の時間ステップⓒ 2018 Information Processing Society of Japan

全体実行時間における大きな差は主にバリア時間から生じ

6

情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31ている．この原因は，preload を用いない場合，毎回の各ノ

通信データサイズも同じになる．ただし，mSMS では，図ードの計算時間がノードによって非常にばらつき（segv に５，６で示したようにページや preload データの転送前に，よるページフェッチの待ち時間が一定でないことも一因と固定サイズの短いメッセージヘッダーを送受信するため，思われる），毎回のバリア同期の度に最も遅いノードを待つ

実際の通信回数は倍になる．また, preload ではデータ領域

ことにより，バリア時間が膨らんでしまう．しかし，今回がすでにローカルノードにキャッシュされているか，連続の実験では， preload を用いて計算時に一切の segv や通信データとして１回の MPI 通信でできるか，MPI 実装においが発生しない状況にしても，各ノードでの計算部分のみのて１回の最大通信サイズを超えないかなどをチェックして時間にばらつきが発生しており，その原因は調査中である．

おり、preload 措定範囲が大きい場合には、この計算オーバ

この計算時間の各ノードのばらつきにより，多数ノードにーヘッドが大きくなる．

なるほどバリア時間が非常に大きくなって，全体の性能をMPI プログラムは，非同期送受信，同期送受信の２種，下げている．単純ステンシルでは，更新回数，バリア回数

マルチスレッドサポートレベルの変更などを行ってみたが，が多いために，preload 利用の有無による各ステップの実

いずれも 128 ノード未満では実行時間に影響はなかった．

行時間のばらつきが顕著に表れる．

しかし，128 ノード以上では，非同期通信よりも同期通信のほうが高速である．図 10 は，同期通信による MPI プログ

3.3 時間ブロッキングステンシル計算 A2 の性能

ラムとの比較を示している．

空間，時間ブロッキングによりデータアクセス局所性を

128 ノード未満における各プログラムの実行時間の処理

高めた時間ブロッキング処理の性能を図９に示す．時間ブ

成分の詳細を分析したところ，1 回当たりの隣接データのロックサイズ(bt)が 16 の場合，近傍データの交換サイズは

送受信時間（２回の MPI 通信）が，mSMS での preload 時間

bt 倍に増えるものの，ノード間のデータ交換回数は 128 回（ユーザスレッドによるデータ要求からデータの受信まで）

から 8 回に減少する．単純ステンシル計算に比べ，全体のの時間よりも長くかかっていることがわかった．詳細に調実行時間は短縮化され，preload の有無による性能差も小さ査しても，この現象は安定しており，これにより，マルチ

くなっているが，128 ノード以上を用いた場合とそれ以下スレッドによる mSMS の同時通信機構が，シングルスレッのノード数では明らかに違う状況が生まれている．ここでドによる MPI プログラムの通信よりも効率的である可能性

は紙面スペースの制限で示していないが，27 点ステンシルがある．

の場合も同様の状況を示す．すなわち，segv 方式の計算時

一方，128 ノード以上の実験では，Tsubame3.0 の利用可

間とバリア時間が 128 ノードを境に急激に増大している．

能な時間的制約から，MPI 通信の詳細状況は調査できていこの原因は，調査中であるが，128 ノード以上とそれ未満の MPI の実装方式が非常に異なることに起因するのは明らかで，SMS ページサイズを大きくして，segv 発生回数と(c)(d)のバリア待ち時間の成分は，単純ステンシル計算 A1に比べるといずれも小さく，preload の有無による短縮化率

Time(sec)

ページ要求回数を減らすと，顕著な差は小さくなる．図９

alltime(s) MPI
Simple 7p stencil Timealltime(s) preload(128GB/node, 24 threads, nt=128)
1000
alltime(s) no preload
919
908
884
900
797
714
700
778
769
707
660
800
737
687
531 637
642
602
683
604
682
564
700
679
556
528
636
509 523
630
589
626
608
630
617
600
603
500
400
300
200
100
0

も 128 ノード未満においては小さい．
単純ステンシル計算と時間ブロッキングステンシルの

2

4

8

16

両方で，時間ステップ毎の同期時には，データ一貫性同期のうち，キャッシュページを破棄する sms_sync_drop を用

図 10 (a)いている．このため，同期時にデータ更新データを owner

2500

作業は省略されている．
GFlops

2000
1500

MPI プログラムと mSMS との性能を比較するため，単純

1000

ステンシルにおける性能を比較した．図 10 に実行時間と500

性能を示す．この結果，128 ノード未満の場合，preload を

96

128

160

180

mSMS と MPI の比較 7 点単純ステンシル計算実行時間0

Simple 7p stencil Performance GFLOPS (nt=128)

2321
2219
2060
1706
2011
1724
1657
1316
1550
1048
1274
935
1328
1059
894 1005 814499
732
133 253 450 382
67
228
35
199
30 3358 55116 102用いると mSMS プログラムのほうが MPI プログラムよりも

GFLOPS (MPI)
GFLOPS(preload)
GFLOPS(No preload)2

高速であることがわかる．
MPI も mSMS プログラムも，実際の隣接ノードとの大域

72

3000

ノードに通知したり，cache ページの更新部分を抽出する

3.4 MPI プログラムとの性能比較

3264
Num of nodes

図 10 (b)

4

8

16

32
64
72
Num of nodes

96

128

160

180

mSMS と MPI の比較 7 点単純ステンシル計算 性能

データの転送の回数は 1 時間ステップあたり 2 回で等しくⓒ 2018 Information Processing Society of Japan7

情報処理学会研究報告
IPSJ SIG Technical Report

Vol.2018-HPC-165 No.22
2018/7/31

ない．しかし，128 ノード以上のクラスタでは，MPI 実装と謝辞

MPI 通信状況が大幅に変化しており，多数ノード利用時の今回の mSMS を使った大規模クラスタ利用実験では，東MPI の利用メモリの増大や，多数ノード時に生成される MPI

京工業大学学術国際情報センターの TSUBAME グランドシステムスレッドなどにより，mSMS の通信スレッドとのチャレンジ大規模計算制度（平成 30 年度春期 6 月カテゴ

利用コアの競合がおきている可能性もあり，今後，調査しリ B）を利用させて頂きました．実験にあたっては，センていく予定である．

ターの関係各位に多くのご支援に頂きましたことをここに

4. 終わりに深謝いたします．

本報告では，マルチノードマルチスレッド向けの高性能

参考文献

SDSM システムとして新たに設計した mSMS を用い，大規[1] 緑川博⼦，飯塚肇 : "ユーザレベル・ソフトウエア分散共有メ
モリ SMS の設計と実装", 情報処理学会論⽂誌ハイパフォー
マンスコンピューティングシステム,Vol.42, No.SIG9(HPS 3),
pp.170-190, (2001,8)[2] 緑川博⼦, 飯塚肇:"メタプロセスモデルに基づくポータブルな
並列プログラミングインターフェース MpC",情報処理学会論
⽂誌：コンピューテイングシステム,Vol.46 No.SIG4(ACS9),
pp.69-85,（2005,3)[3] 緑川博⼦,岩井⽥匡俊："マルチスレッド対応型分散共有メモ
リシステムの設計と実装", ハイパフォーマンスコンピューテ
ィングと計算科学シンポジウム HPCS2015, HPCS2015 論⽂集,（2015,5-19）[4] 緑川博⼦、齋藤和広、佐藤三久、朴 泰祐："クラスタをメモ
リ資源として利⽤するための MPI による⾼速⼤容量メモリ"、情報処理学会論⽂誌，コンピューティングシステム，
Vol.2, No.4, pp.15-36, (2009.12)[5] H. Midorikawa, K.Saito, M.Sato, T.Boku: "Using a Cluster as a
Memory Resource: A Fast and Large Virtual Memory on MPI",
Proc. of IEEE Cluster2009, 2009-09, Page(s): 1-10 ( DOI:
10.1109/CLUSTR.2009.5289180 )[6] 鈴⽊悠⼀郎, 鷹⾒友博, 緑川博⼦："マルチスレッドプログラ
ムのための遠隔メモリ利⽤による仮想⼤容量メモリシステムの設計と初期評価", 情報処理学会、Hokke2011,ハイパフォー
マンス研究会 Vol.2011-HPC-132, No.13, pp.1-6, (2011.11)[7] ⼤浦陽，緑川博⼦, 甲斐宗徳："遠隔メモリ利⽤による OutOf-Core OpenMP プログラムの性能評価実験", 第 15 回情報科
学技術フォーラム FIT2016, FIT2016 論⽂集 第⼀分冊 B004,
p.177-178, 富⼭⼤（富⼭)（2016,9.9）[8] 緑川博⼦, 北川健司, ⼤浦 陽: "マルチスレッドプログラム向け遠隔メモリサーバにおけるページ交換プロトコルの評価実
験",情報処理学会，ハイパフォーマンスコンピューティング
研究会報告（HPC）,2017-HPC-160(36),pp.1-9 ，（秋⽥県秋⽥市）(2017-07-26)[9] M.D. Wael, et al.: “Partitioned Global Address Space Languages”,
Journal of ACM Computing Surveys (CSUR), Vol.47, No.62(2015)[10] Tsubame3
http://www.gsic.titech.ac.jp/tsubame3[11] S. Matsuoka, T. Endo, et.al “Overview of TSUBAME3.0, Green
Cloud Supercomputer for Convergence of HPC”, AI and Big-Data,
GSIC, Tokyo Institute of Technology, e-Science Journal, Vol. 16,
pp. 2–9, 2017[12] 緑川 博⼦ , 北川 健司:"⾼柔軟性と⾼性能を提供するマル
チノードマルチスレッドプログラム向け分散共有メモリシス
テム", 情報処理学会，研究報告ハイパフォーマンスコンピューティング（HPC）,Vol.2018-HPC-163, No.10,pp.1-8 (201802-21)

模クラスタシステムにおいて共有メモリプログラミングモ
デルで記述したステンシル計算の稼働実験を行った．この結果，180 ノードを利用し，各ノードに約 130GB のデータを分散配置して，全体として 23TiB の大域共有データを定義し，約 30TiB の仮想アドレス空間を持つプロセスを各ノードで稼働させて，大規模な共有メモリデータプログラミ
ング環境を実現した．
また，通信が頻繁な単純ステンシルアルゴリズムにおいても，preload 機能などにより，MPI に匹敵する（場合によっては MPI 以上の）性能が mSMS により得られることを示した．通信頻度を低減した時間ブロッキングアルゴリズ
ムにおいては，128 ノード未満のシステムでは，preload 利用の有無での性能差は小さく，segv 方式であっても，MPI
プログラムの性能に近い性能が得られる．
今回の実験で，これまでの 128 ノード未満の状況と，128ノード以上の MPI 通信環境が大幅に違うことが明らかになり，大規模ノードにおいて考慮すべき点，これまでとは違う様々な現象については，今後，調査していく予定である．これまで mSMS は，InfiniBand と MVAPICH を用いて設計，実装してきた経緯もあり，Tsubame3.0 では，通信媒体と MPI 実装が変更されたことにより，性能チューニング
の点で未知の部分がある．preload に関しても，効率を重視する点から連続アドレス領域データは，MPI が許容する最大サイズまで，一度に通信するようにしていたが，大規模ノードでは，一斉に preload が始まると通信バッファサイ
ズなどの点で弊害が生じる可能性もある．また，今回，OSのメモリ管理における overcommit 機能を生かし，物理メモ
リサイズを超える大規模なアドレス空間を持つプロセスを各ノードで実行させたが，これにより既存の MPI 実装などにどのような影響がでるのかも調査が必要と考えている．
また，今後は，ステンシル計算のように MPI で記述しても，それほど，大変ではない応用ではなく，共有メモリプ
ログラミングモデルを生かした応用処理についても性能を調査していく．ただし，いずれの応用においても，メモリ
アクセス局所性を高めたアルゴリズムを用いること第一とし，プログラミング生産性と性能のバランスにおいて，実用に十分利用可能な分野への適用を考えている．

ⓒ 2018 Information Processing Society of Japan

8