ハイパフォーマンスコンピューティングとゲームの”深いぃ関係”

"Close relationship" between

CEDEC 20092009年9月2日（水）

"Close relationship" between

High Performance Computing and Computer Game

佐藤 三久

筑波大学 計算科学研究センター

概要

現在、超ハイエンドの世界最速のスーパーコンピュータは1ペタフロップス（一秒間に、１千兆回の浮動小数点演算）の性能に達しています。

実は、そこで用いられているプロセッサはPS3に使われているCellであるのは有名な話ですが、いまのHPCのトレンドは、GPUなどのゲームと関係の深い先端のテクノロジを使いこなすかが重要になってきています。

一方、通常のPCにおいてもマルチコアあるいはマルチプロセッサになり、そ

2CEDEC 2009

一方、通常のPCにおいてもマルチコアあるいはマルチプロセッサになり、その性能を生かすためには、これまでHPCで行われてきた並列プログラミングが重要になってきています。

このように関係の深い、２つのカテゴリの技術の関係に着目し、並列処理、並列プログラミング技術の概要、これからの技術のトレンドについて概観します。

目次

ＨＰＣ（ハイパフォーマンスコンピューティング）と計算科学 計算科学とは

計算機はどのくらい早くなったか

並列プログラミングについて プログラミングモデル

OpenMP

3CEDEC 2009

OpenMP

メッセージ通信

Asynchronous RPC

マルチコアプロセッサの使い方

なぜマルチコアか ～ マイクロプロセッサのトレンド

マルチコアの分類 SMP vs. AMP

これからのHPCとゲームとの”関係”

4CEDEC 2009

計算科学：第三の科学

第三の科学 実験できない領域

素粒子科学 Quantum chromodynamics（量子色力学）

クオークの質量

宇宙物理学

宇宙の成り立ち

地球温暖化 予測

このまま進むとどうなるか

5CEDEC 2009

第一原理的手法を使用すれば，実験不可能なことでも，シミュレーションによって解明される，であろうことが明らかになりつつある。

バイオ，ナノテクノロジー

現在の計算機リソースでは不可能なものも多い

実験，観測の検証。それでも実験より手軽に実施可能である。

流体シミュレーション、構造設計

自動車、ビル設計、飛行機・ロケットの設計

地球シミュレータ

海洋技術研究所・地球シミュレータセンター

NEC

2002年完成

国産ベクトル計算機として世界最高速

大規模気象シミュレーション等様々な分野で応用

6CEDEC 2009

性能 40TFlops地球環境問題大気循環モデル細かくシミュレーション20kmメッシュ、

用

共有メモリ結合されたベクトルプロセッサ

5120 CPU

計算機はどのくらい早くなったか

能力はどうやって計るのか？ １秒あたりの演算可能回数 Top500 － Linpack(密行列の大規模連立一次方程式の求解）

マイクロプロセッサの発展 クロックスピードにほぼ比例して早くなる 2000年前後にクロックは1GHzに。

7CEDEC 2009

2000年前後にクロックは1GHzに。 しかし、２～3GHzで、クロック速度の進歩はとまった。

スーパーコンピュータは並列処理の時代へ 単一プロセッサでは限界！ スーパーコンピュータは並列処理により早くなっている

TOP 500 Listhttp://www.top500.org/

LINPACKと言われるベンチマークテストを実施する。 密行列を係数とする連立一次方程式を解く

ベクトル機でもスカラー機でも性能が出やすい

例えば地球シミュレータはピーク性能40TFLOPS（設計値）に対して35TFLOPS以上の性能が出ている。

8CEDEC 2009

実際のアプリケーションではこれほどの性能は出ない 差分法，スペクトル法系の手法：ピーク性能の60%程度

AFES on the Earth Simulator： 26 TFLOPS（ピーク性能の65%）

2008年から、電力消費量を表示するようになった これからのスパコンは、電力が大切

Top500 (2008/June)

9CEDEC 2009

Roadrunner

Los Alamos National Lab.

IBM

2008年完成

各ノードにOpteronプロセッサとIBM Cell Broadband Engineを搭載したハイブリッド型クラスタ

世界初のPFLOPSコンピュータ

10CEDEC 2009

世界初のPFLOPSコンピュータ⇒ 2008/6-11, 2009/6の3期連続 TOP500#1

129600プロセッサ1.46 PFLOPS(Linpack: 1.11 PFLOPS)

Blue Gene/L

Lawrence LivermoreNational Lab.

IBM

2005年完成

組み込み用低性能プロセッサを非常に多数ネットワーク結合

素粒子計算、流体計算等

65536 CPU360 TFLOPS

System

11CEDEC 2009

Chip(2 processors)

Compute Card(2 chips, 2x1x1)

Node Board(32 chips, 4x4x2)

16 Compute Cards

System(64 cabinets, 64x32x32)

Cabinet(32 Node boards, 8x8x16)

2.8/5.6 GF/s4 MB

5.6/11.2 GF/s0.5 GB DDR

90/180 GF/s8 GB DDR

2.9/5.7 TF/s256 GB DDR

180/360 TF/s16 TB DDR

PowerPC440組込CPU改

TSUBAME

東京工業大学

SUN Microsystems +NEC

2006年完成

各計算ノードをmulti-core CPU (dual-coreOpteron) とアクセラレータ（ClearSpeed) によって構成したハイブリッドクラスタ

計算科学全般

12CEDEC 2009

計算科学全般

655 nodes/10480cores

109.7TFLOPS（アクセラレータ込み）

T2K-Tsukuba

13CEDEC 2009

筑波大学計算科学研究センター.

Appro International + Cray Japan

2008年完成（6月稼動開始）

ノード性能とネットワーク性能をコモディティとして最高レベルに上げたPCクラスタ

計算科学全般

2592 CPU chip = 10368 CPU core95 TFLOPS

計算機はどのくらい早くなったか

能力はどうやって計るのか？ １秒あたりの演算可能回数 Top500 － Linpack(密行列の大規模連立一次方程式の求解）

マイクロプロセッサの発展 クロックスピードにほぼ比例して早くなる 2000年前後にクロックは1GHzに。

14CEDEC 2009

2000年前後にクロックは1GHzに。 しかし、２～3GHzで、クロック速度の進歩はとまった。

スーパーコンピュータは並列処理の時代へ 単一プロセッサでは限界！ スーパーコンピュータは並列処理により早くなっている

プロセッサ研究開発の動向

クロックの高速化、製造プロセスの微細化 いまでは3GHz, 数年のうちに10GHzか！？

インテルの戦略の転換 ⇒ マルチコア

クロックは早くならない！？

プロセスは65nm⇒45nm , 将来的には32nm

トランジスタ数は増える！

Good news & bad news!

15CEDEC 2009

アーキテクチャの改良 スーパーパイプライン、スーパースカラ、VLIW…

キャッシュの多段化、マイクロプロセッサでもL3キャッシュ

マルチスレッド化、Intel Hyperthreading

複数のプログラムを同時に処理

マルチコア：１つのチップに複数のCPU

インテル® Pentium® プロセッサ

エクストリーム・エディションのダイ

Good news & bad news!

プログラミングに関係するところ

Moore’s Law reinterpreted

15年で、クロックの速度の進歩はとまった。

トランジスタ数だけは、増加している。何につかうのか？

16CEDEC 2009

うのか？

マルチコア

１８ヶ月で、チップあたりのコア数は倍に

計算機はどのくらい早くなったか

能力はどうやって計るのか？ １秒あたりの演算可能回数 Top500 － Linpack(密行列の大規模連立一次方程式の求解）

マイクロプロセッサの発展 クロックスピードにほぼ比例して早くなる 2000年前後にクロックは1GHzに。

17CEDEC 2009

2000年前後にクロックは1GHzに。 しかし、２～3GHzで、クロック速度の進歩はとまった。

スーパーコンピュータは並列処理の時代へ 単一プロセッサでは限界！ スーパーコンピュータは並列処理により早くなっている

ＴＯＰ500：全世界のスパコンランキング５００位

18CEDEC 2009

今年１ＰＦのシステム（RoadRunner)が登場

Top1はいろいろ変動しているが、sumとtop500は、ほぼ一直線

これは、ムーアの法則だけではなく、台数効果、つまり並列処理

2017年ごろには1ExaF

Top500の性能 ＝ Moore’s Law × 並列度

スパコン（高性能システム）のトレンド

CPU性能 ＣＰＵ

メモリ

ＣＰＵ ＣＰＵ

ＣＰＵ

19CEDEC 2009

CPUとメモリの性能の差が広がっている集積度が上がっているためその割にはメモリとチップのピンネックになっているメモリバンド幅を向上させるにはコストが高いそれに大して、チップ側は比較的簡単に集積度を上げることができるベクトルは、メモリにお金をかける分だけ高価メモリをつかわない（キャッシュを利用する）プログラムにする必要がある。

メモリ

年代

ＣＰＵ

メモリT2K(2008)

160 Gflops(40)、40GB/sec(10)⇒0.25B/F

CP-PACS(1996)300MF

2.0GB/s(?)>= 4B/F

並列システムはなぜ有効か

複数のノードを結合することにより、実行のメモリバンド幅（aggregate)を増やすことができる。

これからは、数万ノードの時代

もちろん、ノードの性能を引き出すことも重要

安いCPUのテクノロジーを利用できる。

ネットワークの性能が重要になる。

ＣＰＵ

メモリ

ベクトルプロセッサでＣＰＵの性能を上げた分だけ、メモリバンド

幅を上げる⇒ しかし、高々数倍

20CEDEC 2009

ネットワークの性能が重要になる。

ＣＰＵ

メモリ

ＣＰＵ

メモリ

ＣＰＵ

メモリ

ＣＰＵ

メモリ

ネットワーク

数万個のノードを結合

メモリバンド幅はノード数倍になる

並列処理の問題点：「アムダールの法則」の呪縛

アムダールの法則

逐次処理での実行時間をT1, 逐次で実行しなくてはならない部分の比率がαである場合、pプロセッサを用いて実行した時の実行時間（の下限）Tpは、Tp = α＊T1 + (1-α)＊T1/p

つまり、逐次で実行しなくてはならない部分が10%でもあると、何万プロセッサを使っても、高々１０倍にしかならない。

21CEDEC 2009

実行時間

逐次部分

並列部分

逐次実行 Pプロセッサ並列実行

1/p

並列処理の問題点：「アムダールの法則」の呪縛

「Gustafsonの法則」：では実際のアプリではどうか？ 並列部分は問題規模によることが多い

例えば、ノード数nの場合、n倍の大きい問題を解けばよい。n倍の問題は、計算量がnになると、並列処理部分は一定

Weak scaling – プロセッサあたりの問題を固定←大規模化は可能

Strong scaling －問題サイズを固定 ←こちらはプロセッサが早くなくてはならない。

22CEDEC 2009

実行時間

逐次実行 nプロセッサ並列実行

n倍の問題逐次実行

n倍の問題並列実行

システム総電力 P = N ×α×C×V×F並列システムの消費電力

１０PFLOPS超のシステムの実現に当たって最も重要な課題は消費電力と設置スペース

現在のPC(10GFLOPS/100W）で10PFLOPSシステムを作ると、100万プロセッサで、電力は100MW必要

1PFLOPSならば、現状の延長線にあるが、10PFLOPSでは再検討が必要

マルチコアによる低電力化

超ハイエンドスパコンとマルチコアによる「低電力化」

23CEDEC 2009

並列処理による低電力化のアプローチNを増やし 、 Vとfを押さえ 、システム性能 N×fを向上

Vとf を抑えることにより、チップ内の発熱密度、電力を抑える微細加工技術の進歩 130nm ⇒ 90nm⇒65nm,45nm（CとVを低減）低電力プロセッサ技術の活用（αを抑える）

システム総電力 P = N ×α×C×V×F並列システムの消費電力

P = N×α×C×V２×f

CPU数 プロセッサ回路の稼動率

プロセッサ回路容量

駆動電圧 クロック周波数

ＨＰＣとゲームの”深いぃ関係”（その１）

今のハイエンドのスーパーコンピュータは、かつてのベクトルコンピュータとは違い、「通常の」（コモディティ）プロセッサをコンポーネントを基本としている。 高性能プロセッサ、マルチコア、低電力プロセッサ、…

これをたくさん集めたもの

（ネットワーク）

24CEDEC 2009

むしろ、高性能なゲームプロセッサ技術によって、生まれたコモディティ技術が、これからのハイエンドシステムを牽引する RoadrunnerとCell BE

GPU技術から生まれたGPGPU（General Purpose GPU)

共有メモリ型

CPU CPU CPU CPU複数のCPUが一つのメモリにアクセスするシステム。

それぞれのCPUで実行され

ているプログラム（スレッド）

25CEDEC 2009

ＭＥＭ

BUSているプログラム（スレッド）は、メモリ上のデータにお互いにアクセスすることで、データを交換し、動作する。

大規模サーバSMPマルチコアプロセッサ

分散メモリ型

CPU CPU

MEM MEM

Network

CPUとメモリという一つの計算機

システムが、ネットワークで結合されているシステム

それぞれの計算機で実行されているプログラムはネットワークを

26CEDEC 2009

CPU CPU

MEM MEM

Network いるプログラムはネットワークを通じて、データ（メッセージ）を交換し、動作する

クラスタ計算機AMP マルチコア

（高速化のための）並列処理の簡単な例

for(i=0;i<1000; i++)S += A[i]

1 2 3 4 1000

+ S

逐次計算

並列計算

27CEDEC 2009

1 2 1000250 251 500 501 750 751

+ + + +

+S

並列計算

プロセッサ１ プロセッサ２ プロセッサ３ プロセッサ４

マルチスレッドプログラミング

共有メモリプログラミングの基礎

スレッド：一連のプログラムの実行を抽象化したもの

プロセスとの違い プロセスは、スレッド＋メモリ空間（メモリプロテクション）

POSIXスレッド pthread たくさんのプログラムが同時に実行されている

28CEDEC 2009

スレッド

POSIX threadライブラリ

スレッドの生成 thread_create

スレッドのjoin pthread_join

同期, ロック

#include <pthread.h>

void func1( int x ); void func2( int x );

main() {pthread_t t1 ;pthread_t t2 ;

pthread_create( &t1, NULL,(void *)func1, (void *)1 );

pthread_create( &t2, NULL,(void *)func2, (void *)2 );

main

pthread_create

29CEDEC 2009

(void *)func2, (void *)2 );printf("main()¥n");pthread_join( t1, NULL );pthread_join( t2, NULL );

}void func1( int x ) {

int i ;for( i = 0 ; i<3 ; i++ ) {

printf("func1( %d ): %d ¥n",x, i );}

}void func2( int x ) {

printf("func2( %d ): %d ¥n",x);}

func1

func2pthread_join

pthread_create

pthread_join

POSIXスレッドによるプログラミング

スレッドの生成

for(t=1;t<n_thd;t++){r=pthread_create(thd_main,t)

}thd_main(0);

Pthread, Solaris thread

ループの担当部分の分割

足し合わせの同期

int s; /* global */int n_thd; /* number of threads */int thd_main(int id){ int c,b,e,i,ss;c=1000/n_thd;

30CEDEC 2009

thd_main(0);for(t=1; t<n_thd;t++)

pthread_join();

c=1000/n_thd;b=c*id;e=s+c;ss=0;for(i=b; i<e; i++) ss += a[i];pthread_lock();s += ss;pthread_unlock();return s;

}

スレッド＝プログラム実行の流れ

OpenMPによるプログラミング

#pragma omp parallel for reduction(+:s)

for(i=0; i<1000;i++) s+= a[i];

これだけで、OK!

31CEDEC 2009

OpenMPとは http://www.openmp.org/

共有メモリマルチプロセッサの並列プログラミングのためのプログラミングモデル OpenMP Architecture Review Board (ARB)が仕様を決定 Oct. 1997 Fortran ver.1.0 API 現在、OpenMP 3.0

新しい言語ではない！ コンパイラ指示文（directives/pragma）、ライブラリ、環境変数によりベース言語

を拡張 ベース言語：Fortran77, f90, C, C++

32CEDEC 2009

ベース言語：Fortran77, f90, C, C++ Fortran： !$OMPから始まる指示行 C: #pragma omp のpragma指示行

自動並列化ではない！ 並列実行･同期をプログラマが明示

指示文を無視することにより、逐次で実行可 incrementalに並列化 プログラム開発、デバックの面から実用的 逐次版と並列版を同じソースで管理ができる

OpenMPの実行モデル

逐次実行から始まる

Fork-joinモデル

… A ...#pragma omp parallel

Afork

Parallel region: 複数のスレッド(team)によって、

並列実行される部分 Parallel構文で指定

同じParallel regionを実行するスレッドをteamと呼ぶ

region内をteam内のスレッドで重複実行

関数呼び出しも重複実行

33CEDEC 2009

#pragma omp parallel{

foo(); /* ..B... */}… C ….#pragma omp parallel{… D …}… E ...

Call foo() Call foo()Call foo()Call foo()B

C

D

E

join

Work sharing構文

Team内のスレッドで分担して実行する部分を指定

parallel region内で用いる

for 構文

イタレーションを分担して実行

データ並列

sections構文

各セクションを分担して実行

thread1 thread2 thread3

34CEDEC 2009

各セクションを分担して実行

タスク並列

single構文

一つのスレッドのみが実行

parallel 構文と組み合わせた記法

parallel for 構文

parallel sections構文

directiveswork-sharing, sync

Duplicated execution

For構文

Forループのイタレーションを並列実行

指示文の直後のforループはcanonical shapeでなくてはならない

varは整数型のループ変数（強制的にprivate）

#pragma omp for [clause…]for(var=lb; var logical-op ub; incr-expr)

body

35CEDEC 2009

varは整数型のループ変数（強制的にprivate）

incr-expr

++var,var++,--var,var--,var+=incr,var-=incr

logical-op

＜、＜＝、＞、＞＝

ループの外の飛び出しはなし、breakもなし

clauseで並列ループのスケジューリング、データ属性を指定

例Matvec(double a[],int row_start,int col_idx[],double x[],double y[],int n){

int i,j,start,end; double t;#pragma omp parallel for private(j,t,start,end)

for(i=0; i<n;i++){start=row_start[i];end=row_start[i+1];t = 0.0;for(j=start;j<end;j++)

疎行列ベクトル積ルーチン

36CEDEC 2009

for(j=start;j<end;j++)t += a[j]*x[col_idx[j]];

y[i]=t;}

}

X y

a[col_idx[j]]

A

a

並列ループのスケジューリング

プロセッサ数４の場合

逐次

schedule(static,n)

n Iteration space

37CEDEC 2009

Schedule(static)

Schedule(dynamic,n)

Schedule(guided,n)

Data scope属性指定

parallel構文、work sharing構文で指示節で指定

shared(var_list)

構文内で指定された変数がスレッド間で共有される

private(var_list)

構文内で指定された変数がprivate

firstprivate(var_list)

private

38CEDEC 2009

privateと同様であるが、直前の値で初期化される

lastprivate(var_list)

privateと同様であるが、構文が終了時に逐次実行された場合の最後の値を反映する

reduction(op:var_list)

reductionアクセスをすることを指定、スカラ変数のみ

実行中はprivate、構文終了後に反映

Barrier 指示文

バリア同期を行う

チーム内のスレッドが同期点に達するまで、待つ

それまでのメモリ書き込みもflushする

並列リージョンの終わり、work sharing構文でnowait指示節が指定されない限り、暗黙的にバ

39CEDEC 2009

リア同期が行われる。

#pragma omp barrier

motionestimation

predictdct_type

estimationtransform putpict

iquantizecalcSNR itransform

並列化の例：MediaBench

MPEG2 encoder by OpenMP.

/*loop through all macro-blocks of the picture*/

#pragma omp parallel private(i,j,myk)i

40CEDEC 2009

#pragma omp parallel private(i,j,myk)

{

#pragma omp for

for (j=0; j<height2; j+=16)

{

for (i=0; i<width; i+=16)

{

... loop body ...

}

}

}

j

i

OpenMPのプログラム例：laplace

Laplace方程式の陽的解法

上下左右の4点の平均で、updateしていくプログラム

Oldとnewを用意して直前の値をコピー

典型的な領域分割

最後に残差をとる

41CEDEC 2009

OpenMP版 lap.c

3つのループを外側で並列化

OpenMPは１次元のみ

Parallel指示文とfor指示文を離してつかってみた

void lap_solve(){

int x,y,k;double sum;

#pragma omp parallel private(k,x,y){

for(k = 0; k < NITER; k++){/* old <- new */

#pragma omp forfor(x = 1; x <= XSIZE; x++)for(y = 1; y <= YSIZE; y++)uu[x][y] = u[x][y];

/* update */#pragma omp for

for(x = 1; x <= XSIZE; x++)

42CEDEC 2009

for(x = 1; x <= XSIZE; x++)for(y = 1; y <= YSIZE; y++)u[x][y] = (uu[x-1][y] + uu[x+1][y] + uu[x][y-1] + uu[x][y+1])/4.0;

}}

/* check sum */sum = 0.0;

#pragma omp parallel for private(y) reduction(+:sum)for(x = 1; x <= XSIZE; x++)

for(y = 1; y <= YSIZE; y++)sum += (uu[x][y]-u[x][y]);

printf("sum = %g¥n",sum);}

OpenMP3.0で追加された点

タスクの概念が追加された Parallel 構文とTask構文で生成

されるスレッドの実体

task構文

taskwait構文

www.openmp.orgに富士通訳の日本語バージョンの仕様書がある

struct node {struct node *left;

メモリモデルの明確化 Flushの扱い

ネストされた場合の 定義の明確化

Collapse指示節

C++

43CEDEC 2009

struct node *left;struct node *right;

};

void postorder_traverse( struct node *p ) {if (p->left)

#pragma omp task // p is firstprivate by defaultpostorder_traverse(p->left);

if (p->right)#pragma omp task // p is firstprivate by defaultpostorder_traverse(p->right);

#pragma omp taskwaitprocess(p);

}

では、性能は？

プラットフォーム、問題規模による

特に、問題規模は重要 並列化のオーバーヘッドと並列化のgainとのトレードオフ

性能を得るためには…

ロックの方法

キャッシュ

Laplaceの性能

実行時間 対逐次性能比

XSIZE=YSIZE=1000

0.9

3

44CEDEC 2009

キャッシュ

メモリメモリバンド幅

実行時間 対逐次性能比

Core i7 920 @ 2.67GHz, 2 socket

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 2 4 6 8 10 12

0

0.5

1

1.5

2

2.5

0 2 4 6 8 10 12

メッセージ通信プログラミング

分散メモリの一般的なプログラミングパラダイム sendとreceiveでデータ交換をする

ネットワーク

Send Receive

コア１ コア３

45CEDEC 2009

通信ライブラリ・レイヤ POSIX IPC, socket

TIPC (Transparent Interprocess Communication)

LINX (on Enea’s OSE Operating System)

MCAPI (Multicore Communication API）

MPI (Message Passing Interface)

ネットワーク

コア２ コア４

メッセージ通信プログラミング

1000個のデータの加算の例

int a[250]; /* それぞれ、250個づづデータを持つ */

main(){ /* それぞれのプロセッサで実行される */int i,s,ss;s=0;

46CEDEC 2009

s=0;for(i=0; i<250;i++) s+= a[i]; /*各プロセッサで計算*/if(myid == 0){ /* プロセッサ0の場合 */

for(proc=1;proc<4; proc++){recv(&ss,proc); /*各プロセッサからデータを受け取る*/s+=ss; /*集計する*/

}} else { /* 0以外のプロセッサの場合 */

send(s,0); /* プロセッサ0にデータを送る */}

}

MPIによるプログラミング

MPI (Message Passing Interface)

おもに用途は、高性能科学技術計算

現在、ハイエンドの分散メモリシステムにおける標準的なプログラミングライブラリ 100ノード以上では必須

面倒だが、性能は出る

アセンブラでプログラミングと同じ

組み込みシステムのプログラミングには

47CEDEC 2009

アセンブラでプログラミングと同じ

メッセージをやり取りして通信を行う Send/Receive

集団通信もある Reduce/Bcast

Gather/Scatter

のプログラミングには「牛刀」か！？

ネットワーク

Send Receive

MPIでプログラミングしてみると

#include "mpi.h"#include <stdio.h>#define MY_TAG 100double A[1000/N_PE];int main( int argc, char *argv[]){

int n, myid, numprocs, i;double sum, x;int namelen;

48CEDEC 2009

int namelen;char processor_name[MPI_MAX_PROCESSOR_NAME];MPI_Status status;

MPI_Init(&argc,&argv);MPI_Comm_size(MPI_COMM_WORLD,&numprocs);MPI_Comm_rank(MPI_COMM_WORLD,&myid);MPI_Get_processor_name(processor_name,&namelen);fprintf(stderr,"Process %d on %s¥n", myid, processor_name);

....

MPIでプログラミングしてみると

sum = 0.0;for (i = 0; i < 1000/N_PE; i++){

sum+ = A[i];}

if(myid == 0){for(i = 1; i < numprocs; i++){

MPI_Recv(&t,1,MPI_DOUBLE,i,MY_TAG,MPI_COMM_WORLD,&status);

49CEDEC 2009

MPI_Recv(&t,1,MPI_DOUBLE,i,MY_TAG,MPI_COMM_WORLD,&status);sum += t;

}} else

MPI_Send(&t,1,MPI_DOUBLE,0,MY_TAG,MPI_COMM_WORLD);/* MPI_Reduce(&sum, &sum, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD); */MPI_Barrier(MPI_COMM_WORLD);...MPI_Finalize();return 0;

}

MCAPI

MCAPI (Multicore Communication API)

Multicore Association (www.multicore-association.org, Intel, Freescale, TI, NEC)で制定された通信API

March 31, 2008 時点でV1.063

MRAPI (Resource Management API)ともに用いる

MPIよりも簡単、hetero, scalable, fault tolerance(?), general

3つの基本的な機能

50CEDEC 2009

3つの基本的な機能

1. Messages – connection-less datagrams.

2. Packet channels – connection-oriented, uni-directional, FIFO packet streams.

3. Scalar channels – connection-oriented single word uni-directional, FIFO packetstreams.

MCAPI’s objective is to provide a limited number of calls with sufficientcommunication functionality while keeping it simple enough to allowefficient implementations.

メッセージ通信の問題点：並列化はなぜ大変か

ベクトルプロセッサ

あるループを依存関係がなくなるように記述

ローカルですむ

高速化は数倍

並列化

DO I = 1,10000…..

元のプログラム

ここだけ、高速化

51CEDEC 2009

並列化

計算の分割だけでなく、通信（データの配置）が本質的

データの移動が少なくなるようにプログラムを配置

ライブラリ的なアプローチが取りにくい

高速化は数千倍ー数万

元のプログラム

データの転送が必要

プログラムの書き換え

初めからデータをおくようにする！

マルチコアプロセッサ：SMPとAMP

SMP（Symmetric Multi Processor） 同じコアを複数配置したもの

普通は、共有メモリ型

汎用

AMP（Asymmetric Multi Processor） 機能が異なるコアを配置した非対称な型

通常は、分散メモリ型

AMD quad-core

IBM Cell

52CEDEC 2009

通常は、分散メモリ型

Cell プロセッサが有名

GPUやDSPもこれに分類

機能が特化されている ⇒ コストが安い

共有メモリ vs. 分散メモリ 各コアからどのようにメイン・メモリにアクセスできるかもプログラミングを考え

る場合に重要な点

CPUコア DSP

シングルコアでのマルチタスクプログラムが、マルチコア（SMP)で動かない？

シングルコアで優先度が高いタスクの実行中は優先度が低

マルチコアプロセッサの使い方 （その１）

複数のプロセス・スレッドでの利用 主に、共有メモリSMPのマルチコアプロセッサ

通常、組み込みシステムはマルチタスク（プロセス）のプログラム

特別なプログラミングはいらない（はず）

53CEDEC 2009

シングルコアで優先度が高いタスクの実行中は優先度が低いタスクが動かないことが前提としている場合

マルチコアでは＊本当に＊並列に動いてしまい、優先度が無効になる

キチンと同期をとりましょう。

コア１コア１

コア２

マルチコアプロセッサの使い方（その２）

コアごとに異なる機能で使う

AMP型では主な使い方 SMP型でも、共有メモリを持たない場合にはこのタイプ

従来、複数のチップで構成したものを１つに

個々のコアにOSを走らせる。（DSPなどOSがない場合もあり） 違うOSの場合も。LinuxとRTOS

SMPで、VM等を使って違うOSを乗せる場合も同じ

54CEDEC 2009

SMPで、VM等を使って違うOSを乗せる場合も同じ

通信はChip内インタコネクトまたはバス RPCモデルも使える

コア

OS

アプリ

コア

OS

アプリ

Chip間インターコネクト

コア

OS

アプリ

DSP

アプリ

BUS

マルチコアプロセッサの使い方（３）

高性能化のためにつかう (最終的にはみんなこれ？！）

複数のコアで並列処理

共有メモリSMPの場合はOpenMP ハイエンドで使われている技術が使える

AMPでも、DSP等を加速機構としてつかっている場合は、このケースに当たる。

55CEDEC 2009

コア３ コア４

コア１ コア２

プログラム

コアで分担して実行

コア DSP

特別処理プログラム

RPCによるマルチコアプログラミング

RPC (remote procedure call)

別のアドレス空間（通常、共有ネットワーク上の別のコンピュータ上）にある手続きを実行することを可能にする技術

client-server(caller-callee)に抽象化し、通信の詳細を隠蔽

IDL (interface description language)でインタフェースを記述、通信を生成

いろいろな分野・実装・応用がある

SUN RPC – システムサービス

CORBA (common object broker arch)

GridRPC

56CEDEC 2009

GridRPC

マルチコアでも使える

既存のルーチンを違うコアに割り当てる

AMPの形態には自然な抽象化

“ある機能を呼び出す”

もちろん、SMPでもOK

通信を隠蔽してくれるので、

分散メモリ、共有メモリどちらでもよい

コアコア

(or DSP)

手続きプログラム

call

return

RPCの仕組み

client-server(caller-callee)に抽象化し、通信の詳細を隠蔽 IDL (interface description language)でインタフェースを記述、通信を生成

Stub - クライアント側のメソッド呼び出しをサーバにディスパッチ

Skeleton - サーバ側でクライアントに代わってメソッドを呼び出す

手続きのIDL記述

手続きのインタフェース（引数および結果）の情報を記述したもの

IDLコンパイラを使ってStubとskeltonを生成

57CEDEC 2009

コアコア

(or DSP)

手続きプログラム

call

return

stub skeleton

起動・引数を送る

結果を送る

富士通・非同期RPC(ARPC）によるマルチコアプログラミング

富士通が非同期RPC(ARPC）によるマルチコアプログラミングを提案

非同期＝複数のRPCを同時に実行

58CEDEC 2009

通常の逐次プログラムからの移行が簡単

通信を隠蔽することにより、いろいろなコア（&DSP)に対して移植性の良いプログラムができる

⇒ 開発コストの低減

RPCによるマルチコアプログラミングのこれから

逐次プログラムからの移行が容易, いろいろな形態(AMP&SMP、DSP)に対応

directiveベースのプログラミング環境も提案されている

HMPP (hybrid multicore parallel programming)@INRIA

StarSs @BSC

59CEDEC 2009

ＨＰＣとゲームの”深いぃ関係”（その２）

マルチコアとなっている、今の高性能プロセッサを使いこなすためには、ＨＰＣで培われてきた並列プログラミング技術が役に立つ 共有メモリプログラミング： OpenMP

メッセージ通信プログラミング：ＭＰＩ ⇒ MCAPI

RPC プログラミング

…

マルチコアでも、メモリが共有されていない場合には、プログラミン

60CEDEC 2009

マルチコアでも、メモリが共有されていない場合には、プログラミングが大変

専用組み込みプロセッサでは、標準化（の不在） 組み込みプロセッサ・システムは形態が多様

Chip内のインターコネクトの通信ソフトウエア

MCAPI (Multicore Communication API)は本命？

標準的な（高レベルな）プログラミングモデル、簡便なプログラミング環境が期待されている ⇒ ARPC ? OpenMP?

Beyond the “Petaflops”

Approaches to “Exaflops” (10^18 百京回／秒）

1,000PFlops@2017±2 (predicted by Top500)

これまでは、台数（ノード数）を増やすことによって、スピードを達成してきた。（weak scaling …）

これからはコア数（演算器）を増やす(strong scaling)ことしかできない。

61CEDEC 2009

２つの大きな問題： Power constraints

Memory wall

(efficiency)

Strong Scalingのための演算加速機構

演算を別のUnit（ボード）にoff-loadする

演算に特化した、専用な

アーキテクチャが可能

nVIDIAのシェダープロセッサ

専用のメモリアーキテクチャを使うことができる

GDDR3

実際の例

演算加速機構unit

CPU

Memory

I/O

62CEDEC 2009

GPGPU (General-Purpose Graphic Processing Unit)

GPUをグラフィックだけでなく、数値計算などの一般の演算に使えるように拡張したもので、非常に活発に研究が行われている。

CUDAが提案されたことで、プログラミングが、簡単になった

nVIDIA GeForce, Tesla,…

いまでは、OpenMPでの並列化も提案されている(PGI OpenMP)

Cell BE

ClearSpeed

Intel Larrabee (many core)

代表的な演算加速機構

理論ピークメモリバンド幅

141.7GB/s

(= 64bit * 8 * 2.214GHz )

MP数: 30

MPの内部構成• SP数: 8

(全体で240シェダープロセッサ)

993GFlops

共有メモリ: 16KB

レジスタ数: 16K本(64KB)

GeForce GTX280

63CEDEC 2009 http://news.cnet.com/8301-13512_3-10006184-23.htm よりl

(64KB)

富士通研究所 成瀬氏のスライドから

性能は？ ClearSpeed Advance e620（以下 ClearSpeedと表記)

NVIDIA TeslaC870

(以下 Teslaと表記)

CPU:AMD Quad-CoreOpteron 2.0GHz × 2

(メモリ：DDR2-800 16GB)

標準のライブラリで、FFTと0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

2^20 2^21 2^22 2^23 2^24 2^25

GLOPS

CPU Tesla ClearSpeed

FFT

64CEDEC 2009

標準のライブラリで、FFTと行列積の性能を比較

行列積 転送量が演算量に

比べて、相対的に少ない GPGPUに有利

ＦＦＴ やはり、GPGPUは、演算

が早い

2^20 2^21 2^22 2^23 2^24 2^25

問題サイズ

0

20

40

60

80

100

120

140

1024 2048 3072 4096 5120 6144 7168 8192 9216 10240行列サイズ

GFLOPS

CPU C870 e620

行列積

演算加速機構の問題点

演算加速機構(GPGPU)のメモリにデータがおいておける場合には、非常に効果的

特にメモリバンド幅が大きい。グラフィックと融合した場合。

姫野BMTで、メモリバンド幅効率80%超、理論ピーク142GB/sに対して、実効で115GB/sを実現 [成瀬2009]

１つのGPGPU以上に性能を上げようとおもうと、…

GPGPUのボードを複数装着

演算加速機構を持ったノードで並列化

現在のところ、余り有効ではない

65CEDEC 2009

現在のところ、余り有効ではない

IOの速度が非常に遅い

GPGPU同士の直接結合

演算加速機構unit

CPU

Memory

I/O

演算加速機構unit

CPU

Memory

CPU

Memory

I/O

演算加速機構unit

CPU

Memory

I/O

演算加速機構unit

CPU

Memory

CPU

Memory

I/O

演算加速機構unit

CPU

Memory

I/O

演算加速機構unit

CPU

Memory

CPU

Memory

I/O

演算加速機構unit

CPU

Memory

I/O

演算加速機構unit

CPU

Memory

CPU

Memory

I/O

ここがおそい！

おわりにーＨＰＣとゲームの”深いぃ関係”（その３）

ハイエンドのスパコンでも、これからの高性能化に向けて、StrongScalingが重要になってきた。 ゲームで育ったGPGPUなど、演算加速機構が注目されている。

Strong Scalingを可能とする、スパコン向けに開発・利用されるテクノロジーは、ゲームでも直接使える可能性が高い。 ⇒ 目的が、共有できるようになってきた。

66CEDEC 2009

次世代のGPGPUアーキテクチャ＝メニーコアプロセッサ（e.g. Intel Larrabee,次のCell BE?)

演算加速機構を結合するためのIOインタフェース(e.g. PCI Gen3)

演算加速機構間のインターコネクト

ゲームやPCに使われるテクノロジでないと、スパコンにも使えない。⇒ スパコンが生き残るための"エコシステム”問題 スパコンはそれ自体では投資を回収できない

ご静聴、ありがとうございました。

67CEDEC 2009