アクセラレータ の 将来

東京大学五島 正裕

2011/09/07

R2P/IST 技術講演会

2

はじめに (1/2)

予言：

「アクセラレータ は先細り」

「ディジタル LSI は，メモリと， ARM マルチコア と FPGA だけになる」

危機感：

もし予言が成就したら，日本の LSI ベンダはどうなるのか？ LSI ベンダのない工業国はアリなのか？

自分はともかく，ウチの卒業生はどうなるのか？

R2P/IST 技術講演会

3

はじめに (2/2)

今日の内容：

危機感の共有

予言の証明

しかし，明らかに説得力がない

自分を含め，そう思っている人には かなり自明 感覚の問題で，説明できない

自分の仕事は予言の成就 アクセラレータがどうなろうが，研究的にはどうでもよい

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 技術講演会

11

SIMD プロセッサ

単一の制御部からの指令により，複数の演算器が同時に同じ処理を行う

R2P/IST 技術講演会

Memory

Control Unit

Broadcast

PE – 1 PE– n-1PE – 0 PE – 2

Instruction

12

SIMD 命令セット

（スーパ）スカラ・プロセッサの拡張命令セット

VIS (Visual Instruction Set)

MMX/SSE/3DNow! ， AltiVec ， etc.

元々は， 64b の演算器を， 16b x 4 として使う手法 (VIS ， MMX)

1 つのレジスタ内に，２～ 8 個程度のデータをパック し，

1 命令で，同種の演算を２～ 8 個程度同時に行う

R2P/IST 技術講演会

SIMD の利点と問題点

利点： 性能‐面積効率，最大性能

演算器間で制御部を共有可能 「 1 命令で n 個の処理」

演算器により多くの面積を割り当てることが可能

問題点： プログラマビリティ

13

R2P/IST 技術講演会

背 景 ： 製 品 開 発

R2P/IST 技術講演会

14

背景 0 ： 製品開発

現在の情報機器

1. 要求される処理の高度化 / 複雑化

2. 過当競争による 開発期間の短縮

3. 速度は， 1st. Priority ではなくなりつつある

16

R2P/IST 技術講演会

背景 1 ： ハードウェア (LSI) 開発

1. 要求される処理の高度化 / 複雑化

「設計できない」 ソフトウェアでも開発は難しくなりつつある

2. 開発期間の短縮

「発売に間に合わない」 製品の開発を始めてから LSI の開発を始めるのではダメ

3. 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 技術講演会

20

HW/SW インタフェース

垂直統合：

性能のために HW/SW インタフェースが決まってしまう

その結果，プログラマが泣く

水平分業：

プログラマビリティを第一に HW/SW インタフェースを決める

マイクロアーキテクト / プログラマは，個別に努力する

昔からこうだが，今後はもっとこう

R2P/IST 技術講演会

SIMD と プログラマビリティ

2011/09/07

R2P/IST 技術講演会

22

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– 汎用ベクトル処理

R2P/IST 技術講演会

23

問題は SoA

プログラマビリティに与える制約

AoS ： 単に， 64b ( ， 128b ，… ) の演算だと思えばよい

SoA ： 4 個（， 8 個，…）まとめて演算しなければならない

AoS/SoA は，使い方の問題ではあるが，アーキテクチャに影響を与える

AoS を指向するなら， 4 つ組で十分

SoA によって最大性能の向上を図るなら， 64bx8 なども考えられる

大規模な SIMD プロセッサは SoA （もしくは， AoS の SoA ）

ベクトル・プロセッサは？

R2P/IST 技術講演会

SoA のプログラマビリティに対する制約

規則的 (regular) なループ：

SIMD 化可能

配列の連続要素に対し，同一の処理を行う場合など 積和演算 行列積

不規則 (irregular) なループ：

SIMD 化困難 SIMD 化すると，性能向上が見られない，性能が低下する

24

R2P/IST 技術講演会

25

不規則なループ

1. if-then-else 構造を持つもの

実行フラグなどにより対処は可能だが，性能は悪化 then パート と else パートを逐次実行

2. 不規則なメモリアクセスを含むもの

要素毎にポインタを含むものなど リスト・ベクトル機能

– SIMD 命令セットの範疇では，サポートできない

3. ループからの脱出

コンパイラ (inc. Intel コンパイラ）は SIMD 化しない（最近は？）

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)

Rank

SiteComputerProcessorYear Vendor

Cores Rmax Rpeak

Rmax /

Rpeak

1 RIKENJapan

K computer, SPARC64 VIIIfx2011 Fujitsu

548352 8162.00 8773.63 93.0%

2 NSC in TianjinChina

Tianhe-1A , Intel Xeon, NVIDIA GPU 2010 NUDT

186368 2566.00 4701.00 54.6%

3 DOE/SC/Oak Ridge NLUnited States

Jaguar, AMD Opteron 6 2009 Cray Inc.

224162 1759.00 2331.00 75.5%

4 NSC in ShenzhenChina

Nebulae, Intel Xeon, NVIDIA Tesla GPU2010 Dawning

120640 1271.00 2984.30 42.6%

5 Tokyo Institute of TechnologyJapan

TSUBAME 2.0, Intel Xeon, NVIDIA GPU2010 NEC/HP

73278 1192.00 2287.63 52.1%

… … … … … … …

10 DOE/NNSA/LANLUnited States

Roadrunner, IBM Cell / AMD Opteron2009 IBM

122400 1042.00 1375.78 75.7%

… … … … … … …

NCSA, UIUCUnited States

Blue Waters, IBM POWER720XX 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 技術講演会

スーパスカラ・プロセッサの回路面積

42

1 42 8

回路面積

w

R2P/IST 技術講演会

キャッシュ， I/O

演算器

制御

O(w3) から 実質 O(w) にするアーキテクチャ技術

ステージ ユニット 提案技術

命令フェッチ 命令キャッシュディスパッチ・イメージ・

キャッシュリネーミング RMT

ディスパッチ

命令ウィンドウスケジューリン

グマトリクス・スケジューラ

発行 クラスタ化

レジスタ読み出し 演算器

レジスタ・ファイル

バイパス

非レイテンシ指向レジスタ・キャッシュ・シス

テム実行

レジスタ書き戻し

メモリ依存解析 依存解析器 NOSQ

演算器の追加 演算器ツインテール・アーキテク

チャ43

R2P/IST 技術講演会

スーパスカラ・プロセッサの回路面積

44

回路面積

R2P/IST 技術講演会

1 42 8w

キャッシュ， I/O

演算器

制御

45

評価

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

R2P/IST 技術講演会

Insn Unit

L1 I$

RMT

InstructionWindow Reg

File

LSQ

: OoO Control

: Cache

: Functional Unit

: Inter Processor Router, Memory Controller, IO …

FP FU(x4)

INT FU

(x8)

L2 CacheTag Array

L2 CacheControl

L2 CacheData Array

(3MB)L1 D$

20

mm

20mm

: Instruction Fetch UnitInsn Buf

R2P/IST 技術講演会

46

2011/09/07

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%100%Cache Functional Unit OoO ControlFetch Unit IO Other

R2P/IST 技術講演会

47

2011/09/07

0 50 100 1500

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

OoO-Prop-8wOoO-Prop-4wOoO-Prop-2wOoO-Prop-1wOoO-Base-8wOoO-Base-4wOoO-Base-2wOoO-Base-1wInorder-8wInorder-4wInorder-2wInorder-1w

Area

IPC

R2P/IST 技術講演会

48

2011/09/07

No L2 64KB 128KB 256KB 512KB 1MB 2MB0

1

2

3

4

5

6

7

OoO-Prop-8wOoO-Prop-4wOoO-Prop-2wOoO-Prop-1wOoO-Base-8wOoO-Base-4wOoO-Base-2wOoO-Base-1wInorder-8wInorder-4wInorder-2wInorder-1w

L2 Cache Capacity

IPC

per

Are

a

R2P/IST 技術講演会

49

2011/09/07

50

結果から言えること

面積効率に最も影響を与えるのは，キャッシュの容量

x86 的 汎用マルチコアのキャッシュは，面積効率的には多すぎる

128K ～ 256K では， OoO 2 ～ 4way がよい

0K ～ 64K では，スカラ， 1 ～ 2way がよい

「固定費」であるキャッシュ， I/O の割合が多い →

way 数を増やして，演算器を増やした方がよい

総合的には

同じ性能ならコア数が少ない方がよいことを考え合わせると， 「 x86 的 汎用マルチコア，キャッシュ少なめ」がよい

R2P/IST 技術講演会

51

評価は適正か？

評価の問題

面積の精度は高くない

SPEC しかない IPC の平均しかない 並列化されてない

SPEC CPU 2006

最適化の程度は， CS のプロから見ると，高くない

CS が専門ではない，その分野のエース級プログラマが書いた？

実際あり得る最適化の程度をかなりうまく反映している？

R2P/IST 技術講演会

52

SPEC CPU 2006 INT

Name Lang Description Name Lang Description

400.perlbench

CPERL Programming Language

458.sjeng C Artificial Intelligence: chess

401.bzip2 C Compression 462.libquantum

CPhysics: 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

R2P/IST 技術講演会

53

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

433.milc C Quantum Chromo-dynamics 454.calculix C/Fortran Structural Mechanics

434.zeusmp Fortran Physics / CFD 459.GemsFDTD

FortranComputational Electromagnetics

435.gromacs C/Fortran

Biochemistry/Molecular Dynamics

465.tonto Fortran Quantum Chemistry

436.cactusADM

C/Fortran Physics / General Relativity 470.lbm C Fluid Dynamics

437.leslie3d Fortran Fluid Dynamics 481.wrf C/Fortran Weather Prediction

444.namd C++Biology / Molecular Dynamics

482.sphinx3 C Speech recognition

447.dealII C++ Finite Element Analysis

R2P/IST 技術講演会

おわりに

2011/09/07

R2P/IST 技術講演会

55

Divergence と Convergence

Divergence へ向かわせる圧力

演算能力の不足

消費電力の過剰

Convergence へ向かわせる圧力

製造コストの上昇

機能の高度化・複雑化 → SW 開発コストの上昇

⇓ 少品種大量生産

プログラマビリティ

R2P/IST 技術講演会

56

Convergent Evolution

Convergent Evolution （収斂進化）

1. 汎用マルチコアの面積効率を高める

2. アクセラレータのプログラマビリティを高める

同じようなところに至る

棲み分けはできるか？ → おそらく， No

その時，どちらが「強い」か

1. 前者の方が，道が真っ直ぐで， HW/SW の技術的蓄積が多い

2. 後者は，改良を重ねるたびに，ちょっとずつ違うものになってしまう

例えば， GPU にキャッシュを追加するとか

R2P/IST 技術講演会

57

Convergent Evolution

「 x86 的 汎用マルチコア，キャッシュ少な目」が有望

x86 vs. ARM なら， ARM が有利

命令セット x86 に比べれば， ARM の方がだいぶマシ

下から攻めたほうが勢いがある 歴史は繰り返す（？）

実際， Atom は負けつつある

R2P/IST 技術講演会

58

予言

予言：

「アクセラレータ は先細り」

「ディジタル LSI は，メモリと， ARM マルチコア と FPGA だけになる」

データに基づかない：

汎用マルチコア と アクセラレータ は，比較困難 現状では，製造プロセス，動作周波数などが違いすぎる

データに基づく予測：

汎用マルチコアは，大型コア × 少数 が 小型コア × 多数 よりよい この結果を，汎用マルチコア vs. アクセラレータ に外挿すれば…

R2P/IST 技術講演会

59

やっておくべきこと

「来年，アクセラレータがなくなる」という話ではない

逆に，「ゆでガエル」にならないか心配

汎用マルチコアの研究

コアの面積効率の向上

キャッシュの利用効率の向上

アクセラレータの研究

当面は，プログラマビリティの向上

「いつか止める心づもり」

R2P/IST 技術講演会