...

研究計画 ポストペタ時代のメモリ階層の深化に 対応するソフトウェア技術

by user

on
Category: Documents
18

views

Report

Comments

Transcript

研究計画 ポストペタ時代のメモリ階層の深化に 対応するソフトウェア技術
ポストペタ時代のメモリ階層の深化
に対応するソフトウェア技術
遠藤敏夫
東京工業大学 学術国際情報センター
1
私が使ってきた並列計算機 (~2005)
Fujitsu AP1000+
Distributed memory
IBM/Appro Blade cluster
Xeon x 2CPU x 200node
SMP cluster
Sun Enterprise 10000
Ultra SPARC x 64CPU
Shared memory
SGI Origin 2000
R10000 x 128CPU
Shared memory (NUMA)
私が使ってきた並列計算機(2006~2010)
TSUBAME 1.0 -> 1.1 -> 1.2
(NEC/Sun)
Opteron x 16 CPU core x 655 node
+ClearSpeed x 360 board
+Tesla S1070 x680GPU
2006—07に日本最速
アクセラレータ・GPUを大規模
利用する世界初の運用スパコン
Jun06
Nov06
Jun07
Nov07
Jun08
Nov08
Jun09
Linpack性能
(TFlops)
38.18
47.38
48.88
56.43
67.70
77.48
87.01
Top500順位
7
9
14
16
24
29
41
Opteron
CS x 360
Heterogeneous Linpack [Endo et al. IPDPS08, 10]
CS x 648
Xeon
Tesla
私が使ってきた並列計算機(2010~)
TSUBAME 2.0 (NEC/HP)
Xeon x 12core x 1408 node
+Tesla M2050 x 4224GPU
日本初のLinpack 1PFlops超え
金属凝固シミュレーションで
Gordon Bell賞
1.192PFlops
Nov 2010 Top500 世界4位
世界一グリーンな運用スパコン賞
問題意識
• 並列計算機のアーキテクチャは複雑化の一方
– 原因は電力制限、プロセス周波数の頭打ち、ビッグ
データなど新アプリケーション分野の対応…
– CPU + GPU, Intel MICなどのヘテロなプロセッサの利用
– メモリ階層も複雑化
• 単純な密行列演算(Linpack)でさえ、効率利用はプ
ログラミングコストが大変
• 複雑なアーキテクチャ上で、複雑な演算を、より
ユーザフレンドリーに実現するには、応用アルゴ
リズム、システムソフトウェア、アーキテクチャのモ
デル化にまたがった研究が必要
5
JST-CREST「ポストペタ」プロジェクト (H24/10~H30/3)
ポストペタ時代のメモリ階層の
深化に対応するソフトウェア技術
• ポストペタ時代の気象・医療・防災シミュレーションの
大規模化・高性能化実現に向けて、メモリウォール問
題の悪化が妨げとなる
• システムソフトウェア・アーキテクチャ・アプリにまた
がったco-designにより問題解決を図る
異種メモリ階層アーキテクチャ を想定
• HMC, NVRAMなど次世代メモリ技術含む
階層活用システムソフトウェアの研究
• コンパイラ・ランタイム・メモリ管理の連携により
アプリの局所性向上を自動/半自動で実現
次世代大規模・高性能シミュレーションの実現
ポストペタ時代に実現が求められる
安全・安心社会のためのシミュレーション
約50種のシミュレーションが要求する
メモリ容量・帯域見積もり (100TFlopsあたり)
100000
要求メモリ帯域 (GB/s)
実現困難
10000
1000
100
10
1
10
100 1000 10000
要求メモリ容量(GB)
(計算科学ロードマップ白書の図を一部変更)
既存HW/SW技術の延長で
多様な要求に応えられるか?
7
ポストペタ時代におけるメモリウォール問題の悪化
プロセッサ性能とメモリ(DDR系)性能予測
100000
1000
帯域不足で低性能
10000
Latency core
(GF)
Trghput core
(GF)
DDR (GB)
100
10
1
2008
要求メモリ帯域
(GB/s)
bandwidth (GB/s)
Memory
Speed (GF) , BW(GB/s) , Capacity
(GB)
10000
2012
2016
2020
Year
※ メモリ電力がシステムの20%と仮定
現在のHW技術(DDR系DRAM) の延長
では、提供可能な
• 演算速度あたりの帯域 (B/F)
• 演算速度あたりの容量 (B/FLOPS)
が低下してしまう
容量
不足
1000
100
OK
2018年DDR系DRAM
のパラメータ
(メモリ電力は20%)
10
1
10
100 1000 10000
Memory size (GB)
要求メモリ容量(GB)
OK領域に含まれるアプリを増やす必要!!
単純なアプローチ:
多数ノードの利用、別スパコンアーキ利用
 エネルギー・計算資源利用効率に難
8
既存のアプローチと本研究のアプローチ
アプリの「手動」局所性向上によ
る、キャッシュの効率利用
• Level3 BLAS
 カーネルをライブラリ化できる
計算だけではない
• ステンシル計算の空間ブロッ
キング・時間ブロッキング
• 京のRSDFTの局所性向上ア
ルゴリズム
 アプリ開発コストを押し上げ
る;さらに複雑化するアーキへの
対応が困難
アプリ特性に合わせたスパコ
ンアーキの開発
 設計パラメータはメモリだ
けではなく、無尽蔵に大規模
システムは構築できない
本研究のアプローチ:
異種メモリ階層+階層利用システムソフトウェア
9
多様化するメモリアーキテクチャ技術の活用
Hybrid Memory Cube (HMC)
• DRAMチップの3D積層化による
高帯域化
• DDRより電力あたり容量は不利
• Micron/Intelなど
次世代 不揮発メモリ(NVRAM)
• DRAMと異なる記憶方式
• アクセス速度・密度・write耐性まちまち
100000
DDR
メモリ帯域 (GB/s)
10000
?
1000
STT-MRAM
ReRAM
他、PCM,
FeRAM・・・
高速Flashメモリ
• PCI-Express直接接続・デバイス並列
化によりO(GB/s)の帯域
• Solid State Accelerator(SSA)とも
100
Fusion-io社ioDrive
10
1
10
100 1000 10000
メモリ容量(GB)
いずれも、2018年
ごろの見積もり
10
想定するスパコンアーキテクチャ
5,000~100,000nodes (1~20MW)
HMC
32GB
1TB/s
40GB/s
DDR
100GB
NVRAM?
320GB/s
Vector+Scalar
10TFlops
– 図は、メモリ電力20%を仮定した例
であり、メモリ構成自体も研究対象
~20GB/s
Flash SSA 1TB
Interconnect
[ノード]
• 10TFlops, 200W
• HMC, DDR, Flash SSAなどの異種メ
モリ階層を持つ
Parallel FS
• リモートノードのメモリも階層に含
まれる
[ネットワーク]
例: ショートカット技術を利用した広帯
域・低直径ネットワーク
研究のねらい:
トレードオフを持つ異種メモリを有効活用し、大規模・高性能
シミュレーションを実現するシステムソフトウェアの研究開発
メモリ階層対応
システムソフトウェア
11
想定するシステムのメモリ階層と,
プロトタイプとしてのTSUBAME2.0階層
Typical Cluster
L1
L2,L3
CPU mem
(DDR)
Local storage
(HDD)
Shared storage
TSUBAME2.0
Future
L1
L1
L2
GPU mem
(GDDR)
CPU mem
(DDR)
Local storage
(FLASH)
L2,L3,L4
DRAM+NVRAM
Shared storage
Local storage
HMC
Addressable
FLASH
Rack level storage
Shared storage 12
本研究で取り組む技術的課題
メモリ階層の有効活用のため、下記課題の実現に取り組む
システムソフトウェアのレイヤ
(a) データの階層間配置・移動
で、アプリ開発コストを抑制し
(b) アプリの局所性向上
つつ実現
(c) 強スケーラビリティ確保
これらの実現により、OK領域に入るアプリを増やす
HMC
帯域不足で低性能
10000
10000
容量
不足
1000
100
(a)により、原理的に
容量不足のケース
を排除
100000
Memory bandwidth (GB/s)
要求メモリ帯域 (GB/s)
100000
DDR Flash/Remote
OK
10
(b)により、各シミュ
レーションの要求帯
域を削減
1000
100
10
1
10
100 1000 10000
要求メモリ容量(GB)
1
10
100 1000 10000
Memory size (GB)
要求メモリ容量(GB)
13
研究開発するソフトウェア要素
アプリ
連続体シミュレー
ション
ビッグデータ・グラ
フ解析
各種アルゴリズム
局所性向上・モデル化
ドメイン特化型
フレームワーク
システム
ソフトウェア
大規模数理最適
化問題
メモリ階層対応
ランタイム
リンク
メモリ階層対応
コンパイラ
スワップ処理
スワップ処理
階層対応メモリ管理システム
通信ライブラリ
アーキ
テクチャ
FLASH with
O(GB/s) BW
NVRAM
HMC
Shortcut
Interconnect
14
各ソフトウェア要素が解決する技術的課題
(a) 階層間配置・
移動
(b) 局所性向上
局所性向上手法の
記述支援
データレイアウト・
ループ構造最適化
メモリ階層対応
ランタイム
メモリ階層対応
コンパイラ
$
HMC
DDR
階層対応メモリ管理システム
通信・スワップ
コスト隠ぺい
スケーラブルな
メモリ資源割り当て
Flash
SSA
Parallel FS
(c) スケーラビリティ
15
研究実施体制
アプリ
連続体シミュレー
ション
大規模数理最適
化問題
ビッグデータ・グラ
フ解析
研究代表者: 遠藤敏夫 (東工大准教授)
ドメイン特化型
遠藤グループ
フレームワーク
ランタイム・アルゴリズム局所性
• 鯉渕道紘(NII)、佐藤仁 (東工大)
システム
メモリ階層対応
• 新規雇用PD1名
ソフトウェア
ランタイム
• 修士・博士学生数名
佐藤幸紀 (JAIST助教)グループ
コンパイラツールチェイン
• 田中清史、請園智玲(JAIST)
メモリ階層対応
• 新規雇用PD1名
コンパイラ
• 修士・博士学生数名
緑川博子 (成蹊大助教)グループ
階層対応メモリ管理システム
階層対応メモリ管理システム
• 甲斐宗徳(成蹊大)、技術員1名
• 修士・博士学生数名
FLASH with
O(GB/s) BW
NVRAM
HMC
Shortcut
Interconnect
16
他チームとの連携研究体制
アプリ
ポストペタ藤澤克樹チーム (中央大)
ポストペタ丸山直也チーム (理研)
• 大規模グラフ解析ライブラリ
• 流体シミュレーション
大規模数理最適
ビッグデータ・グラ
連続体シミュレー
• 数理最適化問題 フ解析
• ドメイン特化フレームワーク
化問題
ション
研究代表者: 遠藤敏夫 (東工大准教授)
ドメイン特化型
遠藤グループ
フレームワーク
ランタイム・アルゴリズム局所性
• 鯉渕道紘(NII)、佐藤仁 (東工大)
システム
メモリ階層対応
• 新規雇用PD1名
ソフトウェア
ランタイム
• 修士・博士学生数名
佐藤幸紀 (JAIST助教)グループ
コンパイラツールチェイン
• 田中清史、請園智玲(JAIST)
メモリ階層対応
• 新規雇用PD1名
コンパイラ
• 修士・博士学生数名
緑川博子 (成蹊大助教)グループ
階層対応メモリ管理システム
階層対応メモリ管理システム
• 甲斐宗徳(成蹊大)、技術員1名
• 修士・博士学生数名
FLASH with Jeffrey Vetterグループ
Shortcut
ディペンダブル竹内健
HMCその他連携先:
NVRAM
O(GB/s) BW (ORNL)
Interconnect
• Intel, NVIDIA
チーム (中央大)
• NVRAM・Flash技術
• NVRAM利用スパコン • NEC, HP, Fusion-IO・・・
17
• 東工大TSUBAMEチーム
マイルストーンと数値目標
• 2013年度後半:
– Flash , DDR-DRAM, GDDRからなるメモリ階層を、比較的規則性
の高いプログラムからほぼシームレスに効率利用
• 2015年度前半:
– 次世代スパコン(TSUBAME3.0を想定)上で大規模シミュレーショ
ンコードを実行し、10PFlops, 1PB/s級の性能と, 1PB級の問題規
模を両立
• コードはMPI+CUDAなど、一部はハンドコードもしくは半自動
• 2017年度前半:
– 次々世代スパコン上で大規模シミュレーションコードを実行し、
100PFlops, 10PB/s級の性能と, 10PB級の問題規模を両立
• コードは垂直方向・水平方向ともにメモリ階層を意識せずに記述
18
メモリ階層対応ダイナミックコンパイレーション(佐藤G)
アプリのデータレイアウトとループ階層構造をランタイムに変換し、自動的
に局所性向上を行うコンパイラツールチェーンの研究開発
データの配置・レイアウト最適化
•
•
•
初期配置決定・階層間移動
タイリング、ループ構造に合わせたデータ分割
Structure of array 対 Array of structure
• 膨大なソース中の関数にまたがった局所性
• 動的なワーキングセット変化
• キャッシュ+各メモリ階層の性能特性
ループ階層構造の最適化
• loop unrolling, loop exchange
• loop fusion
• loop distribution blocking
ソースコード情報 and/or
実行中の動的な情報
1. メモリ局所性プロファイラ:
姫野ベンチを佐藤らのデータ依存
解析器にて動的解析した結果。
メモリ参照局所性・データ依存関
係・ループ情報を含む
2. メモリモデルを用いたコード最適化計画: 想定するメ
モリ階層における性能予測を行いコード最適化のプラ
ンを作成
3. 実行時バイナリ変換・ソース変換によるコード最適化:
• 動的コンパイル技術に基づく実行時バイナリ変換
• フィードバック駆動型ソースコード変換
19
メモリ階層対応ランタイムライブラリの開発 (遠藤G)
既存の並列アプリ (例: MPI+CUDA)を少ない変更でメモリ階層に対応させるランタイムラ
イブラリと、それを活用したアルゴリズム局所性向上手法の研究
1. 階層対応ランタイムHHRTの開発
下記のようなモデルに基づくアプリを効率的に実行す
るランタイムの開発
•
•
モデル:並列ソフトウェアは必要十分な細粒度性
を持った仮想プロセス(VP)達から成りたつ
VP単位で階層間を半自動でスワップしながら動
作させるランタイムを開発。スワップコスト・通信コ
スト隠ぺいも
研究期間前半:
MPI+CUDAベース
研究期間後半:
PGAS+OpenACCベー
ス (検討項目)
計算ノード
高位
メモリ階層
VP
低位メモリ階層
HHRTのモデル。UIUC Charmに近い
が半自動スワップに対応
2. アプリアルゴリズム局所性向上の支援
例) 格子系シミュレーションの時間ブロッキング
• 実装が複雑となり実アプリへの取入れはプログラミングコスト高
• 冗長計算の存在のためコンパイラ対応は比較的困難
 HHRTの半自動スワップ機能との組み合わせにより、簡便に大規模・高性能
なシミュレーションを実現
20
階層対応メモリ管理システムの開発 (緑川G)
省電力、大容量の次世代不揮発性メモリ特性を生かしながら、性能向上を実現す
る。1ノード内、垂直方向記憶階層(メモリ,SSA,SSD, HD) と、多ノード連携における水
平方向記憶(局所・遠隔メモリ、共有メモリ・プール)を統一的記憶システムとして利用
するためのシステムソフトウエアの試作、評価を行う。次世代ファイル・メモリ管理方
式、マルチスレッド対応などをOSにフィードバックする。
1. 単一ノード内、垂直方向記憶階層間のキャッシュ/スワップ方式の試作と評価
SSD、遠隔メモリなど各記憶階層間での性能・容量を考慮、OS成熟度に応じた実装方式、
次世代Flashを省電力・大容量・遅いメモリとして利用、寿命確保のための書き込み粒度制御など
2. 静的情報利用による単一ノード/複数ノードにおけるデータ配置と限定的メモリ同期方式の実現
コンパイラ、ユーザによるヒント(API)による、初期データ配置、 規則的繰り返し処理などにおける
限定的データ同期方式
3. 実行時情報利用による単一ノード/複数ノード処理におけ
るデータ配置と限定的メモリ同期方式の実現
実行時メモリアクセス、ワーキングセット見積もり方式の
設計、実行環境(各記憶階層の性能と容量)に応じた
データの移動,の次回繰り返し時の事前データ配置、
データ転送サイズ(粒度)の自動調整
4. 多数ノードに分散するメモリを有効利用するためのメモリ
資源割当方式の実現
複数ユーザ間での多数ノードに分散する記憶装置を有
効利用するための方式
CREST Restricted
メカニカル
1次記憶
短期保存
揮発性
容量
PB
TB
TAPE
HDD
半導体
GB
MB
2次記憶
長期記憶
不揮発性
L1,L2,L3
Cache
DRAM
Memory
次世代
Flash
SSA
SSD
SSS
垂直方向記憶階層
KB
ns
μs
遅延時間
ms
21
局所性向上技術のケーススタディ:
ステンシル計算[金光浩 et al, Hokke 12]
ステンシル計算: 流体シミュレーションなどの重要なカーネル
• シミュレート対象領域を規則格子で表現
• 通常の計算手法では,空間中の全点を更新してから,次の
時間ステップへ
 GPU上で高性能が得られることは実証済(青木研など)
– 通常,局所性は良くない
 多くの前例はGPUメモリサイズ内に限定
多数GPU並列化により,枚数分メモリ容量を利用可能だ
が,それが資源効率・エネルギー効率上,最適なのか?
22
ステンシル計算で
GPUメモリサイズを超えると
• 大計算領域を分割して,一部ず
つGPUメモリに搭載して計算
 1/30程度の,ひどい性能(!)
– cudaMemcpyによるPCIe通信が実
行時間の大半
GPUメモリ超
120
100
実行速度 (GFlops)
– つまり,手動スワップ
– TSUBAME2 1GPU (M2050)
– 三次元の単純7点ステンシル
GPUメモリ内
80
60
40
20
0
0
200
400
600
800 1000 1200 1400
問題サイズ (立方体の一辺)
• 時間ブロッキングの採用により,GPUメモリサイズ超と性
能維持の両立を図る
– 時間ブロッキング:キャッシュの効率的利用・MPI通信の削減のた
めに広まってきた手法
– これを,GPUメモリ ⇔ ホストメモリ活用に応用
23
時間ブロッキングを採用したアルゴリズム
• 一部のデータについて,複数の時間ステップを
先に進めてしまう
– 袖領域が広く必要な欠点  台形の分余分な計算
T0 T2 T4
計算領域
の全体
T0
T1
T0
T1
T2
T3
T4
T0
T1
T2
T3
T4
T3
T1
GPUメモリ
サイズ内
T2
T3
T4
24
計算量の改善手法
• 各部分領域の計算が逐次的であれば,以前の計算
結果を使って台形 平行四辺形とできる
– キャッシュ効率の文脈で京大岩下らの研究あり
Computation
Computation
Communication
Communication
MMT
MMTB
25
評価1: 時間ブロッキングによる
大問題サイズへの対応
TSUBAME2 1 GPU
Problem size: 240 × 240 × 240 ~ 2160 × 2160 × 2160
ブロックサイズは,各条件において最適なものを採用
• 時間ブロッキングにより30~10倍の性能向上
• GPUメモリ内の場合の80~40%の性能を維持
– 右肩下がりの原因は調査中
評価2: 時間ブロックサイズの影響
TSUBAME2 1GPU, Problem size: 720 × 720 × 720
MMT
MMTB
• MMT (台形タイプ): 通信時間と計算時間の間にトレードオフ
⇒ 最適化のためには,モデル化などによりブロックサイズ調整
• MMTB(平行四辺形タイプ): ほぼ「右ほど有利」
• ただし,並列化した場合にはトレードオフ
• 今回の条件では,ブロックサイズ60~90が「スイートスポット」
• 既存研究(キャッシュ効率利用)では4~8が典型的
大規模・高速ステンシルに
ついての展望
• 現状は1GPU, 一次元分割,袖幅1のみ
 並列化,多次元分割
• 時間ブロッキング・各アーキに適合した分割方
向・形状
– 平行四辺形に「削れる」のは,逐次に結果が分かっ
ているときのみ
• 性能モデルによるパラメータ最適化
– 応用の要求FLOP/BYTE
– キャッシュ・GPUメモリ・ホストメモリ・(FLASH)の複数階
層メモリ特性
28
まとめ
• メモリウォール問題の悪化に対し、システムソフトウェア・アー
キテクチャ・アプリ分野にまたがったco-designにより問題解決
を図る
• 次世代気象・医療・防災シミュレーションと次世代メモリ技術と
のギャップを埋め、安心安全社会の実現に貢献
メモリ階層対応
システムソフトウェア
– HMC・NVRAMなどアーキテクチャ分野への要件のフィードバック
– 局所性向上の自動化・パッケージ化によりアプリ・シミュレーション分野
へのフィードバック
– TSUBAME3.0などポストペタスパコンのデザインへのフィードバック
29
Fly UP