2.2.2.

MPI 性能検証
富士通株式会社

志田直之

ここでは，Open MPI および富士通 MPI を用いて，MPI 性能の評価結果について報告する。
1. 性能評価のポイント
MPI の性能評価は，大きく 3 つに分けて評価を行った。
• プロセス数増加に向けた検証• ノード内通信とノード間通信の検証• MPI-IO 性能検証
- 連続データ転送- ストライド転送
2. プロセス数増加に向けた検証
評価に用いたシステムを以下に示す。
CPU
Quad-Core AMD Opteron™ Processor 8354 2.2GHz
4CPU (16core) / node
RAM
16GB /nodeInterconnect
ConnectX DDR HCA * 4OS
Linux version 2.6.18-92.1.22.el5
Topology
FAT Tree
Fujitsu HX600

Fujitsu HX600

HCA

HCA

HCA

HCA

CPU(4core)CPU(4core)

RAM

HCA

CPU(4core)RAM

HCACPU(4core)

RAM

HCA

CPU(4core)

RAM

RAM

HCA

CPU(4core)RAM

CPU(4core)CPU(4core)

RAM

RAM

RAM

CPU(4core)CPU(4core)RAM

CPU(4core)

RAM

RAM

CPU(4core)

Fujitsu HX600

HCA

HCA

HCA

HCA

48ノード

今回の評価に用いたコードと MPI を以下に示す。
Intel® MPI Benchmarks 3.1
コード
MPI
Open MPI 1.3.3
評価は以下の方法で行った。
• ノード内のコアを全て使用 (1 ノード 16 プロセス× 1 ノード)
• ノード内は共有メモリ通信，ノード間 InfiniBand 通信• 現状のユーザーアプリケーションを想定し，測定関数と測定範囲を以下のように設定した- Allreduce (16～768 プロセス)：4B, 8B, 1KB, 32KB
- Alltoall (16～512 プロセス)：1KB, 4KB, 16KB, 32KB
検証結果を以下に示す。

•

Allreduce (16 プロセス/ 1 ノード)
Allreduce (SHM+IB communication) - 16 process/node
100000

10000

usec

1000

100

4B (Recursive Doubling=default)
8B (Recursive Doubling=default)
1KB (Recursive Doubling=default)
32KB (Ring=default)
32KB (Recursive Doubling)

10

1
10100

1000

Processes•

Alltoall (16 プロセス/ 1 ノード)
Alltoall (SHM+IB communication) - 16 process/node
1000000

100000

usec

10000

1000

100
1KB
4KB
16KB
32KB

10

1101001000

Processes

まとめ• Allreduce- 128 プロセス・256 プロセス・512 プロセスの性能値が悪くなるが，相対的にプロセス数とともに実行時間が増えていく。
⇒ 一般的に使用される 4 バイトや 8 バイトの Allreduce は，並列度を上げていくと実行コストが見えてくる。このデータ長は一般的にチェックサムに使用されるため，プロセス数増加しても通信量を減らすことができない。このため，スケーラビリティ低下の要因の一つとなる。
- 32KB では Ring アルゴリズムが選択されるが，実際は 128 プロセスまでは，Recursive
Doubling のアルゴリズムの方が効果的である。

•Alltoall- プロセス数にスケールして，確実に実行時間が増えていく。
⇒ Alltoall を使用したプログラムのスケーラビリティを確保するには，メッセージ長を短くすることが重要となる。

3. ノード間通信とノード内通信評価に用いたシステムを以下に示す。
CPUQuad-Core AMD Opteron™ Processor 8354 2.2GHz
4CPU (16core) / node
RAM
16GB /nodeInterconnect
ConnectX DDR HCA * 4OS
Linux version 2.6.18-92.1.22.el5
Topology
FAT Tree
今回の評価に用いたコードと MPI を以下に示す。
IB + SHM 通信--mca btl_openib_warn_default_gid_prefix 0
実行時--mca btl self,sm,openib
オプション
numactl --interleave=all
実行時付加IB 通信--mca btl_openib_warn_default_gid_prefix 0--mca btl self,openib

numactl --interleave=all

テストパターンと評価システム上のプロセス構成を以下に示す。
• ノード内のコアを全部使用 ( 1 ノード 16 プロセス× 1 ノード)(1) 全ての通信を SHM 通信(2) 全ての通信を IB Loopback 通信
Fujitsu HX600
RAM

CPU(4core)CPU(4core)

RAM

RAM

CPU
(4core)CPU(4core)RAMHCA

•

HCA

HCA

ノード内の CPU を 1 コアだけ全部使用 (4 プロセス/ 1 ノード× 4 ノード)(3) ノード内は SHM 通信，ノード間は IB 通信(4) ノード内は IB Loopback 通信，ノード間は IB 通信
Fujitsu HX600

Fujitsu HX600

HCA

HCA

HCA

CPU(4core)CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU(4core)

Fujitsu HX600

RAM

RAM

HCA

CPU(4core)RAM

CPU(4core)CPU(4core)

RAM

RAM

RAM

CPU(4core)CPU(4core)RAM

CPU(4core)

Fujitsu HX600

RAM

RAM

CPU(4core)

HCA

•

HCA

HCA

HCA

HCA

ノード内の CPU を 1 つだけを使用 (1 プロセス/ 1 ノード× 16 ノード)(5) 全ての通信を IB 通信
Fujitsu HX600

Fujitsu HX600

HCA

HCA

HCA

HCA

16ノード

CPU
(4core)CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU(4core)

RAM

HCA

CPU
(4core)

RAM

RAM

HCA

CPU(4core)

RAM

CPU
(4core)CPU(4core)

RAM

RAM

RAM

CPU
(4core)CPU(4core)RAMCPU(4core)

RAM

RAM

CPU
(4core)Fujitsu HX600

HCA

HCA

HCA

HCA

HCA

検証結果を以下に示す。
• ノード内通信とノード間通信の比較 (PingPong)
PingPong
10000

ノード内通信(SHM通信)
ノード間通信(IB通信)
1000

slow

usec

fast
100

10

1
110100

1000

10000

1000001000000

10000000

1000001000000

10000000

Message size (Byte)•ノード内通信とノード間通信の比較 (Allreduce)
Allreduce
100000

1ノード16プロセス×1ノード (SHM通信)
1ノード16プロセス×1ノード (IB通信)
1ノード4プロセス×4ノード (SHM+IB通信)
1ノード4プロセス×4ノード (IB通信)
10000

1ノード1プロセス×16ノード (IB通信)

usec

slow

1000

fast

100

10
110100

1000

10000

Message size (Byte)•

ノード内通信とノード間通信の比較 (Alltoall)
Alltoall
100000

1ノード16プロセス×1ノード (SHM通信)
1ノード16プロセス×1ノード (IB通信)
1ノード4プロセス×4ノード (SHM+IB通信)
1ノード4プロセス×4ノード (IB通信)

10000

usec

1ノード1プロセス×16ノード (IB通信)

slow
1000

fast

100

10
110100

1000

10000

1000001000000

10000000

Message size (Byte)•

ノード内通信とノード間通信の比較 (Alltoall<一部アルゴリズム変更版>)
Alltoall
100000

1ノード16プロセス×1ノード (SHM通信)
1ノード16プロセス×1ノード (IB通信)
1ノード4プロセス×4ノード (SHM+IB通信)
1ノード4プロセス×4ノード (IB通信)

10000

usec

1ノード1プロセス×16ノード (IB通信)

1000

10010110100

1000

10000

1000001000000

10000000

Message size (Byte)

まとめ• 転送長が短い通信では共有メモリ通信が有利となる。本システム(富士通 HX600)では 20KB がしきい値となり，20KB 以下では共有メモリ通信，20KB 以上がノード間通信の方が速くなる。
• 必要なメモリやメモリバンド幅が気にならないアプリケーションの場合，アプリケーションの選択は以下のように考える。
メッセージ長
全体的に短い全体的に長いノード内プロセス
ノード内に多くのプロセスを詰め込む ノード内のプロセスを減らす
ノード内通信SHM 通信を選択する
IB Loopback 通信を選択する

4. MPI-IO 性能評価に用いたシステムを以下に示す。
• 計算ノード (富士通 FX1)CPUSPARC64 VII 2.5GHz * 1 / node (4-cores)
RAM
32GB /nodeInterconnect
InfiniBand DDR * 1
OSOpenSolaris Build 79
Middleware
Parallelnavi Base Package 3.1
File system
FUJITSU Parallelnavi SRFS 3.0.0-03(B30000-02G)•IO ノード (富士通 SPARC Enterprise M9000)
CPU
SPARC64 VI * 4
RAM64GB /nodeInterconnect
InfiniBand DDR * 4
Fibre Channel
4G-FC * 4File system
Sun StorageTek™ QFS•

ディスクシステム (富士通 ETERNUS2000 Model200)
2
コントローラ数
4GB
キャッシュ容量Interconnect
InfiniBand DDR * 4RAID
RAID6(NL-SAS 4D+2P) *実 WRITE 性能
約 400MB/s
計算ノード
Fujitsu FX1Fujitsu FX1Fujitsu FX1Fujitsu FX1

RAM

RAM

RAM

RAMCPU(4core)
HCA

CPU(4core)
HCA

CPU(4core)
HCA

CPU(4core)

Fujitsu FX18ノード

HCA

IB SW
Fujitsu SPARC Enterprise M9000
64GB
RAM

CPU(2core)CPU(2core)CPU(2core)CPU(2core)

HCA

FC

HCA

FC

HCA

FC

HCA

IOノード

Eternus2000
Model200

FC

富士通の Parallelnavi Language Package V3 に含まれる MPI を使用した。1 ノードあたり 1 プロセスを生成し，以下の観点でテストを行った。
• 連続データ転送性能• ストライド転送性能
計測パターンは 2 種類を用意し，以下のように定義する。
• IO キャッシュ性能： IO サーバーへデータを転送した時間とする。
• ディスク込み IO 性能： 実際にディスクに書き込まれるまでの時間とする。

以下に，連続データの転送性能について評価する。
連続データの転送性能は，以下の API 間の消費時間を計測した。

呼び出すAPI一覧
MPI-IO

Split Files

IOマスター

MPI_File_open
MPI_File_set_view
MPI_File_write
MPI_File_sync
MPI_File_close

open

open
MPI_Gather
write
fsync
close

ディスク込み
IO 性能

write
fsync
close

IO キャッシュ
性能

MPI-IOMPI_File_set_view
MPI_File_write
MPI_File_sync

IOキャッシュ性能
ディスク込みIO性能

I/O 方式
Split Files
write
fsync

IO マスター
MPI_Gather
write (rank0 のみ)
fsync (rank0 のみ)

IO 性能は性能ブレが激しく，数回の試行に対する平均値を性能値と定義することが難しい。例えば，
IO キャッシュの吐き出しタイミングによって大きく性能ブレが発生するが，ユーザープログラムから見るとランダムに発生するため想定できない。
計測は，1 つの IO 長に対し 20 回試行し，明らかに性能ブレしたデータを目視で排除して集計した。
今回提示するデータは，各方式を比較するために「システムが安定しているときの理想的な IO 性能」と考える。
連続データ転送性能は，以下の 3 つのパターンについて計測を行った。
Split Files 方式
各プロセスがファイルを作成する。
MPI_IO 方式
MPI-IO のブロッキング入出力を用いて，一つのファイルを作成する。
IO マスター方式
MPI_Gather によって，全プロセスのデータをルートプロセスに集めてから，一つのファイルを作成する。
検証結果を以下に示す。

2500

連続領域隙間なしのIO性能(write cache bw・write disk cache bw)

バンド幅(MB/s)

2000

MPI-IO

1500

Split Files
IOマスターMPI-IO(ディスク込み性能)
Split Files(ディスク込み性能)

1000

IOマスター(ディスク込み性能)

5000
1.E+06

1.E+07

1.E+08
ファイル長(バイト)1.E+091.E+10MPI-IO 性能と Split Files 性能はほとんど変わらずに，ファイル長が長くなるにつれて傾きは悪くなるがスケールしていく。IO マスター方式は，500MB/s 程度で一定となっている。これは，データの再構成に時間がかかるため，性能面で劣ると言える。
今回評価したシステムでは，ディスク性能が低いため，ディスク込み性能は全ての方式でほぼ同じ性能になっている。MPI-IO 方式・Split Files 方式ともに，IO キャッシュ効果を有効に利用していると言える。
以下に，ストライドデータの転送性能について評価する。
ストライドデータ転送性能は，以下の 3 つのパターンについて計測を行った。
MPI-IO 方式
MPI-IO のブロッキング入出力を用いて，一つのファイルを作成する。
MPI_IO(COLL)方式 集団的 MPI-IO を用いて，一つのファイルを作成する。
IO マスター方式
MPI_Gather によって，全プロセスのデータをルートプロセスに集めてから，一つのファイルを作成する。
計測は，IO キャッシュ性能を測定し，以下の API 間の消費時間を計測した。

呼び出すAPI一覧
MPI-IOMPI-IO(COLL)

IOマスター

MPI_File_open
MPI_File_set_view
MPI_File_write
MPI_File_sync
MPI_File_close

MPI_File_open
MPI_File_set_view
MPI_File_write_all
MPI_File_sync
MPI_File_close

open
MPI_Gather
write
fsync
close

IOキャッシュ性能【ストライド転送性能検証パターン】

1. ファイル長 256MB、ブロック粒度(ファイル長/繰り返し数/プロセス数 )、繰り返し数 (4回)
P00

13

BLOCKLENGTH(可変)COUNT=4

COUNT=1
FILE LENGTH=256MB

2. ファイル長 256MB、ブロック粒度(ファイル長/繰り返し数/プロセス数 )、繰り返し数(16 回)
P00115BLOCKLENGTH( 可変)
COUNT=1

COUNT=16FILE LENGTH=256MB3. ファイル長 256MB、ブロック粒度(ファイル長/繰り返し数/プロセス数 )、繰り返し数(256回)
P00

1255

BLOCKLENGTH=可変
COUNT=1
FILE LENGTH=256MB

検証結果を以下に示す。

COUNT=256

＜ストライド転送性能(ブロック数=4)＞
ストライド転送性能(IOキャッシュ性能)(ファイル長固定=256MB, ブロック数固定=4, ブロック長可変)
1800
MPI-IO

1600

MPI-IO(COLL)

バンド幅 (MB/sec)

1400

IO MASTER

1200
1000
800
600
400
200
0110100

プロセス数＜ストライド転送性能(ブロック数=16)＞
ストライド転送性能(IOキャッシュ性能)(ファイル長固定=256MB, ブロック数固定=16, ブロック長可変)
1800
MPI-IOMPI-IO(COLL)
IO MASTER

1600

バンド幅 (MB/sec)

1400
1200
1000
800
600
400
200
0110100

プロセス数＜ストライド転送性能(ブロック数=256)＞
ストライド転送性能(IOキャッシュ性能)(ファイル長固定=256MB, ブロック数固定=256, ブロック長可変)

バンド幅 (MB/sec)

1800
1600

MPI-IO

1400

MPI-IO(COLL)
IO MASTER

1200
1000
800
600
4002000110
プロセス数

100

ストライドデータのファイル転送では，集団的 MPI-IO の性能が効果的である。16 プロセス実行の比較的小さな環境ではあるが，転送性能はスケールしている。これは，ROMIO における集団的 MPI-IOの実装に，Data Sieving の技術が利用されていることが効果的に働いていると考えられる。DataSieving とは，ストライドデータの入出力処理において，各プロセス内にバッファリングを行い，連続データでファイルを入出力する方法である。2 つのフェーズにわかれていて，出力の場合は通信フェー
ズから I/O フェーズ，入力の場合は IO フェーズから出力フェーズの順に処理を行う。Data Sieving を利用することで，一つ一つの小さなブロックに対するファイル要求ではなく，大きなブロックに対するファイル要求が行われるため，ブロック数が多い場合に効果的な性能が期待できる。
Data Sieving のファイル出力処理を以下に示す。
P001P120P21212

communication

communication
0 0 0
Temporary buffer of P001 1 1
Temporary buffer of P1

writewrite

1. 通信フェーズ

2 2 2
Temporary buffer of P2

2. I/Oフェーズ

FILE
0 0 0 1 1 1 2 2 2

逆に，非集団的 MPI-IO の性能は，ブロック数を増やすにつれて性能の低下が大きい。各プロセスが独立して IO を実行する上で，細かい領域に対してのファイルアクセスに対する排他処理の影響が大きいと考えられる。
以上