parallel and distributed processing

並列と分散

早稲田大学

丸山不二夫 @maruyama097

はじめに：並列と分散

「並列処理(Parallel Processing)」と「並行処理(Concurrent Processing)」の違いは日本語では、必ずしも明確に意識されないことがある。英語でも、その含意には、共通の部分も多い。

一方、「並列処理」と「分散処理(Distributed Processing)」は、外延的には、ほとんど同じであると言えるが、関心のフォーカスが異なっているように思う。

はじめに： Cloudと分散システム

こうしたフォーカスの違いは、次のような我々の感覚、Cloudのサービス提供のシステムを並列処理のシステムとしてよりはむしろ、分散システムとして捉えようとする志向と結びついている。

小論では、「並列から分散へ」という視点からネットワーク上のノードが協調動作をする「分散処理」と単一メモリー空間内の「並行処理」との対比で、システムの発展を考えて見る。

はじめに： multi-coreとInternet

こうした問題意識は、続々と登場しつつあるmulti-coreチップが、システム・デザインに与えるであろう影響を評価する上で重要であると考えている。

同時に、こうした問題意識は、誕生以来、その成長がIT技術に深い影響を与え続けている、我々が知りうる最大の分散システムとしてのInternetから、我々が何を学ぶべきかを考える、ヒントを与えてくれると考えている。

Leslie Lamport “My Writings” での単語の出現数

http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html

Parallel 29個

Concurren* 116個

Distribut* 195個





Multi-core化の進行

続々と投入されるmulti-coreチップ

CPU名コア数製造会社

Nehalem-EX 8 Intel

Power 7 8 IBM

Magny-Cours 12 AMD

Rainbow Falls 16 Sun(Oracle)

Intel SCC (Single-chip Cloud Computer)

Intel Labが2010年3月30日に発表。

http://techresearch.intel.com/articles/Tera-Scale/1826.htm





Single-chip Cloud Computer

このネーミングは、Cloud上にある、スケーラブルなコンピュータのクラスターを、シリコン・チップ上に統合したものだからという。

一つのタイル(tile)につき二つのIAコアを持つ24個のタイルから構成される。48コア

セクション間双方向256GB/secの帯域を持つ、24個のrouter mesh network

4つの統合されたDDR3コントローラ。64GB

メッセージ・パッシングのハードウェア・サポート

Sequentialなプログラミング

並列・分散のない時代に戻ってみよう。

「人生は、善良でシンプルであった。」

Jim Waldo

TheValue クラス

Public class TheValue {

private int theValue;

public TheValue(int initialValue){

theValue = initialValue;

}

public void set(int newValue){

theValue = newValue;

}

public int get(){

return theValue;

}

}

TheValue クラスの逐次実行

TheValue theValue = new TheValue(0);

theValue.set(1);

theValue.get(); // 1 が返る

theValue.set(2);

thevalue.get(); // 2 が返る

theValue.set(3);

theValue.set(4);

theValue.set(5);

theValue.get(); // 5 が返る

Multi-Thread プログラミング (1) 排他制御

「ツールと優秀なプログラマだけが、Multi-Threadについて考えることが必要」

「我々は、順序を失う（複数のことが同時に起こる）。

これは、難しい。なぜなら、我々は、自然には、シーケンシャルに考えるから」

Jim Waldo

TheValueのMulti-Threadでの実行

theValue.set(2);

theValue.set(3);

theValue.set(7);

theValue.set(5);

theValue.set(8); theValue.set(6);

?

Syncronizedの利用

public syncronized void set(int newValue){ theValue = newValue; }

theValue.set(2);

theValue.set(3);

theValue.set(7);

theValue.set(5);

theValue.set(8);

theValue.set(6);

TheValue クラス





}

public syncronized void set(int newValue){


}

public int get(){

return theValue;

}

}

?

Javaのメモリーモデル

メモリー

キャッシュ

レジスター

Public class TheValue { private int theValue; …… …… }

あるスレッドが書き込んだ変数が、他のスレッドから正しく読めるか?

同じスレッドなら、正しく読める。

変数に対する読み書きが、同じLockでモニターされている場合。

syncronized

java.util.concurrent.lock.Lock

変数がvolatile宣言されている場合。

syncronizedとvolatile

syncronized

ロックを持っている一つのスレッドだけを実行

ブロックに入るときにキャッシュをクリア

ブロックを出るときにキャッシュをフラッシュ

volatile

変数を書き出す時にキャッシュをフラッシュ

変数を読み込む前にキャッシュをクリア

TheValue クラス





}



}

public syncronized int get(){

return theValue;

}

} setもgetも同時実行できない

TheValue クラス


private volatile int theValue;



}



}

public int get(){

return theValue;

}

}

setは、同時実行できない getは、同時実行できる

Java.util.concurrent.atomic.*


private AtomicInteger theValue;


theValue = new AtomicInteger(initialValue);

}

public void set(int newValue){

do { int old = theValue.get(); }

while( ! theValue.compareAndSet(old, newValue)

}

public int get(){

return theValue.get();

}

}

Atomic命令 CAS(Compare and Set)の利用

/* Atomically increments by one the current value.

* @return the previous value

*/

public final int getAndIncrement() {

for (;;) {

int current = get();

int next = current + 1;

if (compareAndSet(current, next))

return current;

}

}

Atomic命令 CAS(Compare and Set)の利用

public final int addAndGet(int delta) {

for (;;) {

int current = get();

int next = current + delta;

if (compareAndSet(current, next))

return next;

}

}

java.util.concurrent.lock.* BoundedBuffer （続く）

class BoundedBuffer {

final Lock lock = new ReentrantLock();

final Condition notFull = lock.newCondition();

final Condition notEmpty = lock.newCondition();

final Object[] items = new Object[100];

int putptr, takeptr, count;

java.util.concurrent.lock.* BoundedBuffer （続く）

public void put(Object x) throws InterruptedException {

lock.lock();

try {

while (count == items.length) notFull.await();

items[putptr] = x;

if (++putptr == items.length) putptr = 0;

++count;

notEmpty.signal();

} finally {

lock.unlock();

}

}

java.util.concurrent.lock.* BoundedBuffer

public Object take() throws InterruptedException {

lock.lock();

try {

while (count == 0) notEmpty.await();

Object x = items[takeptr];

if (++takeptr == items.length) takeptr = 0;

--count;

notFull.signal();

return x;

} finally {

lock.unlock();

}

}

少し複雑な例 LinkedQueue

Item0 Item1 Item2

offer(item3)

Item0 Item1 Item2

Item3 poll()

Item1 Item2

Item0

LinkedQueueの Multi-Threadでの実行

lq.offer(1);

lq.poll();

lq.offer(7);

lq.offer(5);

lq.offer(3); lq.offer(6);

?

LinkedQueue lq = new LinkedQueue();

lq.poll()

java.util.concurrent.*

ConcurrentLinkedQueue<E> リンクノードに基づく、アンバウンド形式のスレッドセーフなキュー。

LinkedBlockingDeque<E> リンクノードに基づく、任意のバウンド形式のブロッキング両端キュー。

ArrayBlockingQueue<E> 配列に連動するバウンド形式のブロッキングキュー。

ConcurrentHashMap<K,V> 取得の完全な同時性および予想される調整可能な更新平行性をサポートするハッシュテーブル。

ConcurrentSkipListMap<K,V> スケーラブルな並行 ConcurrentNavigableMap。

……..

Multi-Thread プログラミング (2) 並列実行

Executor

ExecutorService

ThreadPoolExecutor

class SerialExecutor implements Executor { final Queue<Runnable> tasks = new ArrayDeque<Runnable>(); final Executor executor; Runnable active; SerialExecutor(Executor executor) { this.executor = executor; } public synchronized void execute(final Runnable r) { tasks.offer(new Runnable() { public void run() { try { r.run(); } finally { scheduleNext(); }

Executor

} }); if (active == null) { scheduleNext(); } } protected synchronized void scheduleNext() { if ((active = tasks.poll()) != null) { executor.execute(active); } } }

class NetworkService implements Runnable { private final ServerSocket serverSocket; private final ExecutorService pool; public NetworkService(int port, int poolSize) throws IOException { serverSocket = new ServerSocket(port); pool = Executors.newFixedThreadPool(poolSize); }

ExecutorService

public void run() { // run the service try { for (;;) { pool.execute(new Handler(serverSocket.accept())); } } catch (IOException ex) { pool.shutdown(); } } } class Handler implements Runnable { private final Socket socket; Handler(Socket socket) { this.socket = socket; } public void run() { // read and service request on socket } }

ForkJoin 処理の分割

JSR166y

Divide and Conquer

Result solve(Problem problem) {

if (problem が小さいものであれば)

直接、problemを解け;

else {

problemを独立の部分に分割せよ;

それぞれの部分を解く、subtaskをforkせよ;

全てのsubtaskをjoinせよ;

subresultからresultを構成せよ;

}

}

class MaxSolver extends RecursiveAction { private final MaxProblem problem; int result; protected void compute() { if (problem.size < THRESHOLD) result = problem.solveSequentially(); else { int m = problem.size / 2; MaxSolver left, right; left = new MaxSolver(problem.subproblem(0, m)); right = new MaxSolver(problem.subproblem(m, problem.size)); forkJoin(left, right); result = Math.max(left.result, right.result); } } } ForkJoinExecutor pool = new ForkJoinPool(nThreads); MaxSolver solver = new MaxSolver(problem); pool.invoke(solver);

Thresholdによる差異

Thresholdが大きいと、並列性がきかなくなる Thresholdが小さいと、並列化のためのオーバーヘッドが増える

Work-Stealing

それぞれのWorkerスレッドは、自分のスケジューリングQueueの中に、実行可能なTaskを管理している。

Queueは、double-link Queue(dequeu)として管理され、LIFOのpush,popとFIFOのtakeをサポートする。

あるWorkerのスレッドで実行されるtaskから生成されるsubtaskは、dequeにpushされる。

Workerスレッドは、自分のdequeを、LIFO（若い者が先）の順序で、taskをpopさせながら処理する。

Workerスレッドは、自分が実行すべきローカルなtaskがなくなった場合には、ランダムに選ばれた他のWorkerから、FIFO（古いものが先）のルールで、taskを取る（「盗む」）。

Work-Stealing

WorkerスレッドがJoin操作に会うと、それは、利用可能な別のtaskを、そのtaskが終了したという通知(isDone)を受け取るまで処理を続ける。

Workerスレッドに仕事がなく、どの他のスレッドからも仕事を取ることが出来なかったら、いったん元の状態に戻り、他のスレッドが、同様に全てアイドル状態だということが分かるまでは、そのあとも試行を続ける。

全てアイドルの状態の時には、トップレベルから、別のtaskが投入されるまで、Workerはブロックされる。

Work-Stealの動作

Pool.invoke()が呼ばれるとき、taskはランダムにdequeuに置かれる

Workerがtaskを実行しているとき

たいていは、二つのtaskをpushするだけ

そして、その一つをpopして実行する

そのうち、いくつかのWorkerが、top-levelのtaskを盗み始める

そうして、forkが終わると、taskは沢山のwork-queueに、自然に分散することになる

そうして、時間のかかるSequential部分を実行

ParallelArray データの分割

Extra JSR166y

Parallel Array

select-max をParallelArrayで実装するのは簡単。

ParallelArrayフレームワークは、array上の操作の分割を自動化する。

filtering, 要素のmapping, 複数のParallel Array上のcombination をサポートしている

全ての操作を、一つの並列実行に変換する

ParallelLongArray pa = ParallelLongArray.createUsingHandoff(array, fjPool); long max = pa.max();

Parallel Arrayでサポートされている基本操作

Filtering – 要素の部分を選択

複数のfilterを指定できる

ソートされたParallel Arrayには、Binary searchがサポートされている

Mapping – 選択された要素を、別の形式に変換

Replacement – 新しいParallelArrayを生成

Sorting, running accumulation

Aggregation – 全ての値を一つの値に

Max, min, sum, average

一般的な用途のreduce() メソッド

Application – 選択されたそれぞれの要素へのアクションの実行

ParallelArray students = new ParallelArray(fjPool, data); double bestGpa =

students.withFilter(isSenior).withMapping(selectGpa).max(); public class Student {

String name; int graduationYear; double gpa; } static final Ops.Predicate isSenior = new Ops.Predicate() {

public boolean op(Student s) { return s.graduationYear == Student.THIS_YEAR; } }; static final Ops.ObjectToDouble selectGpa = new Ops.ObjectToDouble() {

public double op(Student student) { return student.gpa; } };

Closureの利用

double bestGpa = students

.withFilter(

{Student s =>

(s.graduationYear == THIS_YEAR) }

) .withMapping(

{ Student s => s.gpa }

) .max();

.net PLINQ

LINQ / PLINQ

LINQ to Objects query:

PLINQ query:

int[] output = arr .Select(x => Foo(x)) .ToArray();

int[] output = arr.AsParallel() .Select(x => Foo(x)) .ToArray();

Sequence Mapping

Asynchronous Mapping

Async Ordered Mapping or Filter

IEnumerable<int> input = Enumerable.Range(1,100); bool[] output = input.AsParallel() .Select(x => IsPrime(x)) .ToArray();

var q = input.AsParallel() .Select(x => IsPrime(x)); foreach(var x in q) { ... }

var q = input.AsParallel().AsOrdered() .Select(x => IsPrime(x)); foreach(var x in q) { ... }

Search

More complex query

int result =

input.AsParallel().AsOrdered()

.Where(x => IsPrime(x))

.First();

int[] output = input.AsParallel() .Where(x => IsPrime(x))

.GroupBy(x => x % 5)

.Select(g => ProcessGroup(g)) .ToArray();

Software Managed Coherence

Multi-Core SCCでの整合性の処理

Multi-Coreが今後取り組むべき課題

We believe software managed coherency on non-coherent many-core is the future trend

A prototyped partially shared virtual memory system demonstrates it can be:

Easy to program

Comparable performance vs. hardware coherence

Adaptive to future advanced usage models

Also opens new research opportunities

Challenges for future research

This revived “software managed coherency” topic opens many “cold cases”

What are the right software optimizations?

Prefetching, locality, affinity, consistency model

And more…

What is the right hardware support?

How do emerging workloads adapt to this?

複数のマシンでの分散処理

「マルチ・マシン (MM) は、同一ネットワーク上のマルチ・プロセスと同じではないのだが、ある人たちは、同じだと考えている」

「我々は、状態を失う。「システム」のグローバルな状態というのは、虚構である。興味深い分散システムには、整合的な状態というものは存在しない。」

Jim Waldo

“A Note on Distributed Computing”

http://www.sunlabs.com/techrep/1994/smli_tr-94-29.pdf

ローカルなプログラミングとリモートなプログラミングを、はっきりと区別すべきだという立場

Jim Waldo et al.

ネットワーク上のシステムで相互作用するオブジェクトは、単一のアドレス空間で相互作用するオブジェクトとは、本来的に異なったやり方で取り扱われるべきであると、我々は主張している。

こうした違いが要求されるのは、ネットワーク上のシステムでは、プログラマは遅延の問題を意識せねばならず、異なったメモリーアクセスのモデルを持ち、並列性と部分的失敗(partial failure)の問題を考慮にいれなければならないからである。

我々は、ローカルとリモートのオブジェクトの違いを覆い隠そうと試みる、沢山のネットワーク・システムを見てきた。そして、これらのシステムは、頑健さと信頼性という基本的な要請を満たすことに失敗していることを示そうと思う。

こうした失敗は、過去においては、構築されたネットワーク・システムの規模の小ささで、隠蔽されていた。しかしながら、近未来に予想される、企業規模のネットワークシステムにおいては、こうした隠蔽は不可能となるであろう。

Leaseを利用した分散Transaction

CloudやBASE概念登場以前で、筆者が知る限り、もっともスマートな分散Transactionのシステムは、分散システムのPartial Failureの問題に対応するためにLease概念を応用した、Jiniのそれであった。

「Jini セミナー 1999」第10章 Transaction http://maruyama.cloud-market.com/summer99/summer99.pdf

http://maruyama.cloud-market.com/summer99/summer99.pdf




Java Spaceを利用した分散システムの排他制御

同様に、分散システムの排他制御の、もっともエレガントな例は、Java Spaceを利用したものであったと思う。

「Rio / JavaSpace セミナー」同期とリソースの共有 http://maruyama.cloud-market.com/summer02/rio.pdf

http://maruyama.cloud-market.com/summer02/rio.pdf




データあるいは処理の分割

Googleの登場は、複数のマシンが協調動作する分散処理技術に、大きな飛躍をもたらした。

ここでは、彼らの中心技術であるMapReduceを対象に、その新しさを考えて見る。

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

searchALL searchA

searchB

searchC

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

maruyama

searchALL searchW

searchX

searchY

searchZ

検索結果は、データの分割の仕方に依存しない

searchALL=searchA+searchB+searchC =searchW+searchX+searchY+searchZ

maruyama

maruyama

maruyama

maruyama

maruyama

searchW

searchX

searchY

searchZ

maruyama

maruyama

maruyama

maruyama

maruyama

searchA

searchB

searchC

結合律と可換律

結合律 searchALL=searchA+searchB+searchC =searchA+(searchB+searchC) =(searchA+searchB)+searchC

可換律 searchALL=searchA+searchB+searchC =searchA+(searchB+searchC) =searchA+(searchC+searchB) =(searchC+searchB)+searchA

MapReduce

MapReduceアルゴリズム適用可能例 LogからURLのアクセス頻度を累計する

mapは、Logファイルを処理して各URL毎に（URL,1）を中間出力する。

mapreduceライブラリは、中間出力をURL毎にまとめる。（中間出力のsort）

reduceは、同じURLをカウントアップして、(URL, total count)として出力する。

URL_W

URL_A

URL_K

URL_K

URL_A

URL_N

URL_A

URL_I

URL_H

URL_O

URL_W,1

URL_A,1

URL_K,1

URL_K.1

URL_A,1

URL_N,1

URL_A,1

URL_I,1

URL_H,1

URL_O,1

URL_A,1

URL_A,1

URL_A,1

URL_H.1

URL_I，1

URL_K,1

URL_K,1

URL_N,1

URL_O,1

URL_W,1

URL_A,3

URL_H,1

URL_I,1

URL_K,2

URL_N,1

URL_O,1

URL_W,1

map sort reduce

先の処理の分散化を考える

map部分の処理は、複数のマシン上で分割可能である。

同様に、reduce部分の処理も、URL_AやURL_Kのようなデータの繰り返しの境界を破らなければ、容易に分割可能である。

問題は、mapの出力を分割してsortして、reduceに渡す方法である。

このとき、mapの出力を、同じキーは同じグループに属するように分割すればいい。

GroupByKeyが本質的

URL_W,1

URL_A,1

URL_K,1

URL_K.1

URL_A,1

URL_N,1

URL_A,1

URL_I,1

URL_H,1

URL_O,1

URL_A,3

URL_H,1

sort reduce

URL_A,1

URL_A,1

URL_A,1

URL_H.1

URL_K,1

URL_K,1

URL_I,1

URL_W,1

URL_N,1

URL_O,1

URL_A,1

URL_A,1

URL_A,1

URL_H.1

URL_I，1

URL_K,1

URL_K,1

URL_N,1

URL_O,1

URL_W,1

partition

URL_N,1

URL_O,1

URL_W,1

URL_I,1

URL_K,2

分散処理可能性

分散処理には、いくつかのタイプが存在する。従来の並列処理では、必ずしも明確に意識されていたとは限らない、分散処理に特有の、しかしながら、実践的には極めて有用な分散処理のある型を考えて見よう。ここでも、分析のモデルはMapReduceである。

分散処理可能性 1

あるデータの集合A={Ai}を、n個のマシン上の同一のプログラムPで処理して、あるデータの集合B={Bj}を生成するとしよう。

SPMD(Single Process Multi Data)

MPI = SPMD + message Passing


分散処理可能性１に次の条件を加えたもの

処理の間、ノード間でデータに関する情報の交換はないものとする。

Dryad = メッセージが構成するグラフ全体を汎用的に処理しようという試み

（おそらく、一般化のし過ぎ）


分散処理可能性2に次の条件を加えたもの

任意のn個のノードが、同一のA={Ai} に対して同一の結果B={Bj}を生み出す

Scalability

ノードを増やしても減らしても、処理の結果は変わらない

強い意味での分散処理可能性

あるデータの集合A={Ai}を、n個のマシン上の同一のプログラムPで処理して、あるデータの集合B={Bj}を生成するとしよう。

かつ、処理の間、ノード間でデータに関する情報の交換はないとしよう。

この時、任意のnに対して、同一のA={Ai} に対して同一の結果B={Bj}を生み出すようなプログラムPが存在するならば、＜A,B,P＞は、強い意味で分散処理可能であるという。

Master Worker Pattern

Master

Worker

Worker

Worker

Worker

Worker

Worker

それぞれのWorkerは、

タスクを一つ取り出して処理せよ！

終わったら、作業を繰りかえせ！

強い意味での分散処理可能性の例


てすきのWorkerは、どんどん働け! 働け! 働け! タスクがなくなるまで働け!



作業終了！休んでよし。


Master/Workerパターンは、強い意味での分散処理可能性を満たす

同一のプログラム： Master/Workerパターンでは、各Workerは、同じ仕事を行う。

情報の交換はない： Master/Workerパターンでは、各Workerは他のWorkerの仕事に関心を持たない。

任意のnに対して同一の結果： Master/Workerパターンでは、処理の結果は、Workerの数によらない。

分散処理可能性から MapReduceを再解釈する

Master/Worker パターンでの Map処理

同じキーを持つデータを、同じノードに集めて整列する Shuffling処理

同じキーを持つデータを、整理する Reduce処理ここでも、Master/ Workerパターンが利用される。

・・・・・・・

・・・・・・・

・・・・・・・

・・・・・・・

・・・・・・・

MAP SHUFFLE REDUCE

分散処理のいくつかの問題

並列と分散

分散処理での一群の処理を、単一ノード（multi-coreを含む）内で行うことが出来る並行・並列処理と、複数のノードをまたいで行う分散処理に分けることが出来る。

もちろん、こうした区別は、相対的なものである。同一ノード内の並列処理を、複数のノードに分散して行うことはできるし、複数のノードをまたいで行う処理も、単一ノード内の並列処理として実現しうるからである。

データの存在様式

並列と分散の両者が分離するのは、主要に問題の「大きさ」による。

問題の「大きさ」は、処理の単純さ複雑さによっても決まるし、対象とするデータの大きさによっても決まる。

データの大きさでは、単一のノードによっては収まりきれず、複数のノードによって保持されるデータが存在する。それは、そうした存在の様式にも拘らず、単一のデータであることに注意しよう。

処理の分割とデータの分割

分散処理の手法を、処理の分割とデータの分割に分けられるとは限らない。分散された処理には分散されたデータが付随し、分散されたデータには、分散された処理が付随するからである。

分散処理の管理主体

分散処理は、物理的には各ノード上で分散して行われるが、論理的には、その処理の目的は明確である。

では、その分散したノードの協調動作は、誰によって管理されているのであろうか?

一つの答えは、管理主体の存在しない、自律的な分散処理である。

ただ、それで十分に効率的であろうか?

To Be Continued.

parallel and distributed processing

Documents