アクセラレータの将来 - 坂井・入江研究室

R2P/IST 技術講演会
アクセラレータの将来
東京大学
五島正裕
2011/09/07
R2P/IST 技術講演会
はじめに (1/2)
 予言：

「アクセラレータは先細り」

「ディジタル LSI は，メモリと，ARM マルチコアと FPGA だけになる」
 危機感：

もし予言が成就したら，日本の LSI ベンダはどうなるのか？


LSI ベンダのない工業国はアリなのか？
自分はともかく，ウチの卒業生はどうなるのか？
2
R2P/IST 技術講演会
はじめに (2/2)
 今日の内容：

危機感の共有

予言の証明
 しかし，明らかに説得力がない

自分を含め，そう思っている人にはかなり自明


感覚の問題で，説明できない
自分の仕事は予言の成就

アクセラレータがどうなろうが，研究的にはどうでもよい
3
R2P/IST 技術講演会
発表の内容
1.
背景
2.
アクセラレータとプログラマビリティ
3.
汎用マルチコアの高効率化
4
R2P/IST 技術講演会
アクセラレータ
2011/09/07
R2P/IST 技術講演会
データ並列性の高い処理
 データ並列性の高い処理

データ処理量が多い


汎用プロセッサで対処しにくい（？）
比較的単純な処理の繰り返し（？）

汎用プロセッサほどの複雑な機構は不要（？）
⇒ 汎用プロセッサ＋アクセラレータ
6
R2P/IST 技術講演会
Divergence

専用ハードウェア

アクセラレータ






SIMD プロセッサ
組み込み用ベクトル・プロセッサ
演算器アレイ型プロセッサ
(GP) GPU
PLAYSTATION 3 Cell BE
汎用マルチコア（小型コア）
タイル・プロセッサ
 Larrabee
 Xbox 360 PX


汎用マルチコア（大型コア）
x86 MC （Intel Core, AMD Opteron)
 SPARC64，POWER


（ウルトラワイド・スーパスカラ・プロセッサ）
7
R2P/IST 技術講演会
アクセラレータの特徴
 アクセラレータの特徴（⇔ 汎用マルチコアと比較）：

SIMD（⇔ MIMD）

ローカル・メモリ（⇔ コヒーレント・キャッシュ）
9
R2P/IST 技術講演会
SIMD
1.
SIMD：Single Instruction stream / Multiple Data stream

SIMD プロセッサ

SIMD 命令セット
2.
利点：ピーク性能
3.
問題点：プログラマビリティ
10
R2P/IST 技術講演会
SIMD プロセッサ
 単一の制御部からの指令により，複数の演算器が同時に同じ処理を行う
Control Unit
Instruction
Broadcast
PE – 0
PE – 1
PE – 2
PE– n-1
Memory
11
R2P/IST 技術講演会
SIMD 命令セット
 （スーパ）スカラ・プロセッサの拡張命令セット

VIS (Visual Instruction Set)

MMX/SSE/3DNow!，AltiVec，etc.
 元々は，64b の演算器を，16b x 4 として使う手法 (VIS，MMX)

1つのレジスタ内に，２～8個程度のデータをパックし，

1命令で，同種の演算を２～8個程度同時に行う
12
R2P/IST 技術講演会
SIMD の利点と問題点
 利点：性能‐面積効率，最大性能

演算器間で制御部を共有可能


「1命令で n 個の処理」
演算器により多くの面積を割り当てることが可能
 問題点：プログラマビリティ
13
R2P/IST 技術講演会
背景：製品開発
14
R2P/IST 技術講演会
背景 0 ：製品開発
 現在の情報機器
1.
要求される処理の高度化 / 複雑化
2.
過当競争による開発期間の短縮
3.
速度は，1st. Priority ではなくなりつつある
16
R2P/IST 技術講演会
背景 1 ：ハードウェア (LSI) 開発
1.
要求される処理の高度化 / 複雑化

「設計できない」

2.
開発期間の短縮

「発売に間に合わない」

3.
ソフトウェアでも開発は難しくなりつつある
製品の開発を始めてから LSI の開発を始めるのではダメ
LSI 製造コストの高騰

「開発費を回収できない」

個別用途向けに開発したのではダメ
 個別用途向け，多品種少量の LSI 開発は困難
17
R2P/IST 技術講演会
背景 2：ソフトウェア開発
 開発効率，メンテナンス効率
1.
要求される処理の高度化 / 複雑化
2.
開発期間の長期化 → 開発コストの高騰
3.
HW の速度向上により，速度に対する要求は飽和しつつある？

（少なくとも，ユーザは必要性を実感していない）
 Java，Ruby などの利用

速度はともかく，開発効率が高い
18
R2P/IST 技術講演会
要求される処理の高度化 / 複雑化
 例えば MPEG

MPEG-2 （1995年）


HW 化をかなり考慮して策定
MPEG-4 AVC (H.264) （2003年）

HW 化は（MPEG-2 ほどには）考慮されていない
– SW でも，正しく書くのは難しい
19
R2P/IST 技術講演会
HW/SW インタフェース
 垂直統合：

性能のために HW/SW インタフェースが決まってしまう

その結果，プログラマが泣く
 水平分業：

プログラマビリティを第一に HW/SW インタフェースを決める

マイクロアーキテクト / プログラマは，個別に努力する
 昔からこうだが，今後はもっとこう
20
R2P/IST 技術講演会
SIMD とプログラマビリティ
2011/09/07
R2P/IST 技術講演会
AoS / SoA
 AoS / SoA

AoS (Array-of-Struct) : struct AoS { float r, g, b, a }[N];

SoA (Struct-of-Array) : struct SoA { float r[N], g[N], b[N], a[N] };
 歴史的には，AoS から SoA へ

AoS


ex） VIS，MMX
– 64b の演算器を 16b x 4 として使う
– {r, g, b, a}, {x, y, z, w} の 4つ組
SoA

ex) SSE
– 汎用ベクトル処理
22
R2P/IST 技術講演会
問題は SoA
 プログラマビリティに与える制約

AoS ：単に，64b (，128b，…) の演算だと思えばよい

SoA ： 4個（，8個，…）まとめて演算しなければならない
 AoS/SoA は，使い方の問題ではあるが，アーキテクチャに影響を与える

AoS を指向するなら，4つ組で十分

SoA によって最大性能の向上を図るなら，64bx8 なども考えられる

大規模な SIMD プロセッサは SoA（もしくは，AoS の SoA）

ベクトル・プロセッサは？
23
R2P/IST 技術講演会
SoA のプログラマビリティに対する制約
 規則的 (regular) なループ：

SIMD 化可能

配列の連続要素に対し，同一の処理を行う場合など

積和演算

行列積
 不規則 (irregular) なループ：

SIMD 化困難

SIMD 化すると，性能向上が見られない，性能が低下する
24
R2P/IST 技術講演会
不規則なループ
1.
if-then-else 構造を持つもの

実行フラグなどにより対処は可能だが，性能は悪化

2.
不規則なメモリアクセスを含むもの

要素毎にポインタを含むものなど

3.
then パートと else パートを逐次実行
リスト・ベクトル機能
– SIMD 命令セットの範疇では，サポートできない
ループからの脱出

コンパイラ (inc. Intel コンパイラ）は SIMD 化しない（最近は？）
25
R2P/IST 技術講演会
不規則なループの具体例 (1/2)
 サーチ：

次にたどるべきノードが動的に決まる
 ソート：

ストアの先が，比較結果によって，要素ごとに異なる
26
R2P/IST 技術講演会
不規則なループの具体例 (2/2)
 MPEG-4 AVC (H.264)：



動き検出 (motion detection)

多重ループからの脱出

適応的な探索
算術符号の符号化，復号化

多数の分岐

適応的なモード切替
デブロッキング・フィルタ

適応的なアルゴリズム
27
R2P/IST 技術講演会
プログラマビリティの低さを証明するもの
 「アクセラレータでやってみました」系の論文

最近は通らなくなってきた
 プログラミング・コンテストの存在

Cell Challenge，GPU Challenge（2010 まで）
 Xbox 360 に対する PLAYSTATION 3 の出だしのつまづき（推測）
 ウチの研究室の学生が，某有名エンコーダの SSE/GPGPU 化を担当

「GPGPU で，CPU w/ SSE に勝つのは困難」
 Top 500

（次のスライド）
28
R2P/IST 技術講演会
Top 500 (June 2011)
Computer
Processor
Year Vendor
1
RIKEN
Japan
K computer,
SPARC64 VIIIfx
2011 Fujitsu
2
NSC in Tianjin
China
3
Rank
Site
Cores
Rmax /
Rpeak
Rmax
Rpeak
548352
8162.00
8773.63
93.0%
Tianhe-1A ,
Intel Xeon, NVIDIA GPU
2010 NUDT
186368
2566.00
4701.00
54.6%
DOE/SC/Oak Ridge NL
United States
Jaguar,
AMD Opteron 6
2009 Cray Inc.
224162
1759.00
2331.00
75.5%
4
NSC in Shenzhen
China
Nebulae,
Intel Xeon, NVIDIA Tesla GPU
2010 Dawning
120640
1271.00
2984.30
42.6%
5
Tokyo Institute of Technology
Japan
TSUBAME 2.0,
Intel Xeon, NVIDIA GPU
2010 NEC/HP
73278
1192.00
2287.63
52.1%
…
…
…
…
…
…
…
10
DOE/NNSA/LANL
United States
Roadrunner,
IBM Cell / AMD Opteron
2009 IBM
122400
1042.00
1375.78
75.7%
…
…
…
…
…
…
…
NCSA, UIUC
United States
Blue Waters,
IBM POWER7
20XX IBM
200000
15000.00
29
R2P/IST 技術講演会
Top 500 から言えること (1/2)
 京は Rmax / Rpeak が高い（93.0%）

コア数が多く，通信オーバヘッド上は不利．だから，

コアの効率が 100% 近くないと達成できない

SIMD は 2-way
 GPU スパコンは，Rmax / Rpeak が低い（50% 程度）

コア数が少なく，通信オーバヘッド上は有利．だから，

コアの効率自体，50% を切っているであろう

SIMD は 32-way （？）
30
R2P/IST 技術講演会
Top 500 から言えること (2/2)
 GPU スパコンは，Rmax / Rpeak が低い（50% 程度）

LINPACK：



比較的 regular なプログラムで，
CS のプロによってカリカリにチューンされているのに，こう
実際：


実用的なプログラムを，
CS が専門でないプログラマが書くと？
 GPU スパコンはもう来ないだろう

それでも GPU WS は残るのか？
 おまけ：

スパコンのベンチマークに LINPACK を選んだのは見識だった？
31
R2P/IST 技術講演会
低いプログラマビリティの罪
 プログラミング自体が難しい

しかも，本質的でない困難が多い
 プログラミングの流れ：

汎用プロセッサでのプログラミング


最適なアルゴリズムの選択 → プログラミング → 最適化
アクセラレータでのプログラミング

効率よく実行可能なアルゴリズムの選択 → プログラミング →
書けない，動かない，思い通りの性能が出ない → 最初からやり直し
 「GPU 鬱」は実在する
32
R2P/IST 技術講演会
汎用マルチコアの面積効率
2011/09/07
R2P/IST 技術講演会
コアの規模と数
 チップ面積一定として，どちらが有利か？

小型のコア × 多数

大型のコア × 少数
 基準：
1.
マルチコアこそ，面積効率が重要
2.
面積効率が同程度なら，コアは少ないほうがよい
38
R2P/IST 技術講演会
1. マルチコアこそ，面積効率が重要
 「マルチコアでは，チップ面積が余っているから，無駄に使ってよい」

⇒ ウソ
 面積と性能の関係：

シングル・コアの時代：


チップ面積の増加 ⇒ チップ・コストの増加
マルチコアの時代：

チップ面積の増加 ⇒ コア数の減少 ⇒ 性能低下
39
R2P/IST 技術講演会
2. 面積効率が同程度なら，コアは少ないほうがよい
 Amdahl の法則 (?)

n コアで n 倍スピードアップは無理
 マルチプロセッサの経験から

「コアの性能が低いと，コア数を増やして勝つのは難しい」
40
R2P/IST 技術講演会
スーパスカラ・プロセッサの回路面積
w:幅

フェッチ幅

発行幅
 キャッシュ，I/O：
O(1) ？
 演算器：
O(w)
 制御部：
O(w3)

各種テーブルを構成する RAM：



ポート数：
O(w)
エントリ数：
O(w)
面積 ∝ （ポート数）2 × （エントリ数）
41
R2P/IST 技術講演会
スーパスカラ・プロセッサの回路面積
回路面積
制御
演算器
キャッシュ，I/O
w
1
2
4
8
42
R2P/IST 技術講演会
O(w3) から実質 O(w) にするアーキテクチャ技術
ステージ
ユニット
提案技術
命令フェッチ
命令キャッシュ
リネーミング
RMT
ディスパッチ・イメージ・キャッシュ
命令ウィンドウ
マトリクス・スケジューラ
ディスパッチ
スケジューリング
発行
レジスタ読み出し
クラスタ化
演算器
レジスタ・ファイル
バイパス
非レイテンシ指向
レジスタ・キャッシュ・システム
メモリ依存解析
依存解析器
NOSQ
演算器の追加
演算器
ツインテール・アーキテクチャ
実行
レジスタ書き戻し
43
R2P/IST 技術講演会
スーパスカラ・プロセッサの回路面積
回路面積
制御
演算器
キャッシュ，I/O
w
1
2
4
8
44
R2P/IST 技術講演会
評価
 Alpha 21464 のフロアプラン

R. Preston, et al.: Design of an 8-wide superscalar RISC microprocessor
with simultaneous multithreading, ISSCC, pp. 334―472 (2002).
 SPEC CPU 2006 の平均 IPC
45
R2P/IST 技術講演会
Instruction
Reg
Window
File
FP FU
(x4)
INT
FU
(x8)
20mm
RMT
Insn
Buf
L1 I$
Insn
Unit
L2 Cache
Tag Array
LSQ
L1
D$
L2 Cache
Control
: Cache
: Functional Unit
L2 Cache
Data Array
(3MB)
: OoO Control
: Instruction Fetch Unit
: Inter Processor Router,
Memory Controller, IO …
20mm
2011/09/07
46
R2P/IST 技術講演会
0%
20%
Cache
2011/09/07
40%
Functional Unit
60%
OoO Control
80%
Fetch Unit
100%
IO
Other
47
R2P/IST 技術講演会
2
1.8
1.6
OoO-Prop-8w
1.4
OoO-Prop-4w
OoO-Prop-2w
1.2
IPC
OoO-Prop-1w
OoO-Base-8w
1
OoO-Base-4w
OoO-Base-2w
0.8
OoO-Base-1w
Inorder-8w
0.6
Inorder-4w
Inorder-2w
0.4
Inorder-1w
0.2
0
0
50
100
150
Area
2011/09/07
48
R2P/IST 技術講演会
7
6
OoO-Prop-8w
OoO-Prop-4w
OoO-Prop-2w
OoO-Prop-1w
OoO-Base-8w
OoO-Base-4w
OoO-Base-2w
OoO-Base-1w
Inorder-8w
Inorder-4w
Inorder-2w
Inorder-1w
IPC per Area
5
4
3
2
1
0
No L2
64KB
128KB
256KB
512KB
1MB
2MB
L2 Cache Capacity
2011/09/07
49
R2P/IST 技術講演会
結果から言えること
 面積効率に最も影響を与えるのは，キャッシュの容量

x86 的汎用マルチコアのキャッシュは，面積効率的には多すぎる

128K～256K では，OoO 2～4way がよい

0K～64K では，スカラ，1～2way がよい
 「固定費」であるキャッシュ，I/O の割合が多い →

way 数を増やして，演算器を増やした方がよい
 総合的には

同じ性能ならコア数が少ない方がよいことを考え合わせると，

「x86 的汎用マルチコア，キャッシュ少なめ」がよい
50
R2P/IST 技術講演会
評価は適正か？
 評価の問題

面積の精度は高くない

SPEC しかない

IPC の平均しかない

並列化されてない
 SPEC CPU 2006

最適化の程度は，CS のプロから見ると，高くない

CS が専門ではない，その分野のエース級プログラマが書いた？

実際あり得る最適化の程度をかなりうまく反映している？
51
R2P/IST 技術講演会
SPEC CPU 2006 INT
Name
Description
Lang
Name
Lang
Description
400.perlbench
C
PERL Programming Language
458.sjeng
C
Artificial Intelligence: chess
401.bzip2
C
Compression
462.libquantum
C
Physics: Quantum Computing
403.gcc
C
C Compiler
464.h264ref
C
Video Compression
429.mcf
C
Combinatorial Optimization
471.omnetpp
C++
Discrete Event Simulation
445.gobmk
C
Artificial Intelligence: go
473.astar
C++
Path-finding Algorithms
456.hmmer
C
Search Gene Sequence
483.xalancbmk
C++
XML Processing
52
R2P/IST 技術講演会
SPEC CPU 2006 FP
Name
Lang
Description
Name
Lang
Description
410.bwaves
Fortran
Fluid Dynamics
450.soplex
C++
Simplex Linear Programming Solver
416.gamess
Fortran
Quantum Chemistry
453.povray
C++
Image Ray-tracing
Quantum Chromo-dynamics
454.calculix
C/
Fortran
Structural Mechanics
433.milc
C
434.zeusmp
Fortran
Physics / CFD
459.GemsFDTD
Fortran
Computational Electromagnetics
435.gromacs
C/
Fortran
Biochemistry/Molecular Dynamics
465.tonto
Fortran
Quantum Chemistry
436.cactusADM
C/
Fortran
Physics / General Relativity
470.lbm
C
437.leslie3d
Fortran
Fluid Dynamics
481.wrf
C/
Fortran
Weather Prediction
482.sphinx3
C
Speech recognition
444.namd
C++
Biology / Molecular Dynamics
447.dealII
C++
Finite Element Analysis
Fluid Dynamics
53
R2P/IST 技術講演会
おわりに
2011/09/07
R2P/IST 技術講演会
Divergence と Convergence
 Divergence へ向かわせる圧力

演算能力の不足

消費電力の過剰
 Convergence へ向かわせる圧力

製造コストの上昇

機能の高度化・複雑化 → SW 開発コストの上昇
⇓

少品種大量生産

プログラマビリティ
55
R2P/IST 技術講演会
Convergent Evolution
 Convergent Evolution（収斂進化）
1.
汎用マルチコアの面積効率を高める
2.
アクセラレータのプログラマビリティを高める
 同じようなところに至る

棲み分けはできるか？ → おそらく，No
 その時，どちらが「強い」か
1.
前者の方が，道が真っ直ぐで，HW/SW の技術的蓄積が多い
2.
後者は，改良を重ねるたびに，ちょっとずつ違うものになってしまう

例えば，GPU にキャッシュを追加するとか
56
R2P/IST 技術講演会
Convergent Evolution
 「x86 的汎用マルチコア，キャッシュ少な目」が有望
 x86 vs. ARM なら，ARM が有利

命令セット


下から攻めたほうが勢いがある


x86 に比べれば，ARM の方がだいぶマシ
歴史は繰り返す（？）
実際，Atom は負けつつある
57
R2P/IST 技術講演会
予言
 予言：

「アクセラレータは先細り」

「ディジタル LSI は，メモリと，ARM マルチコアと FPGA だけになる」
 データに基づかない：

汎用マルチコアとアクセラレータは，比較困難

現状では，製造プロセス，動作周波数などが違いすぎる
 データに基づく予測：

汎用マルチコアは，大型コア×少数が小型コア×多数よりよい

この結果を，汎用マルチコア vs. アクセラレータに外挿すれば…
58
R2P/IST 技術講演会
やっておくべきこと
 「来年，アクセラレータがなくなる」という話ではない

逆に，「ゆでガエル」にならないか心配
 汎用マルチコアの研究

コアの面積効率の向上

キャッシュの利用効率の向上
 アクセラレータの研究

当面は，プログラマビリティの向上

「いつか止める心づもり」
59

Download Report