Working with Konoha

プログラミング言語分散並列実行に関する研究調査

横浜国立大学大学院工学府10GD131 五嶋　壮晃

10/08/02 論文レビュー発表会

Working with Konoha

CPU クロック速度の限界• ムーアの法則

– 「半導体チップに集積されるトランジスターの数は約 2 年ごとに倍増する」という法則

– それに伴い CPU クロック速度も向上すると考えられている

• 近年のチップ速度の限界は 3.5GHz 程度にとどまっている

2

Working with Konoha

マルチコアの時代• ムーアの法則は、マルチコアの領域では達成できており、

CPU に搭載されるコア数は年々増加している– 現在 24cores の CPU が登場し、 2012 年には 48cores

の CPU が登場すると言われている

• これからのソフトウェア・アプリケーション開発は、マルチコアを活かすことでパフォーマンスを向上していく必要がある

3

Working with Konoha

並列プログラミング• マルチコアを活かすために、大きく分けて次の２通りの

プログラミング方法がある– マルチスレッドプログラミング– マルチプロセスプログラミング

• マルチプロセスプログラミングは、プロセス複製のコストが大きいため、コア数を増やしても性能向上させることが難しい

• マルチスレッドプログラミングは、共有メモリを用いているためにロック処理や非決定性を考慮しなければならならい

4

Working with Konoha

並列計算モデル• 並列プログラミングをプログラマが安全かつ容易に記述

できるようにモデル化したもの– 今回は並列ソフトウェア開発のために多くのユーザが

用いている、 Java 言語を扱ったモデルについて調査した

• アクターモデル• CoBox モデル

5

Concurrent Computing Model

CoBox Model

Actor Model

Working with Konoha

論文のリスト1. Rajesh K. Karmani, Amin Shali, Gul Agha. Actor

Frameworks for the JVM Platform: A Comparative Analysis: Proceedings of the 7th International Conference on Principles and Practice of Programming in Java

2. John Ayres, Susan Eisenbach. Stage: Python with Actors: Proceedings of the 2009 ICSE workshop on Multicore software engineering

3. Jan Schäfer, Arnd Poetzsch-Heffter: Writing concurrent desktop applications in an actor-based programming model: Proceedings of the 2010 ICSE workshop Multicore software engineering

6

Working with Konoha

Actor Frameworks for the JVM Platform:A Comparative Analysis

• 背景– マルチコアを活かしたプログラミングをする上でアク

ターモデルが注目を集めている• 目的

– JVM 上でアクターモデルを実装した言語・Framework を分析し、アクターモデルの特徴や性能の違いを示す

7Actor Model on JVM

SALS

AKil

imJav

Act

Jetlan

gSc

ala A

ctors

Acto

r Ar

chite

cture

Acto

rFou

ndry

Working with Konoha

アクターモデル• アクター

– メソッド呼び出しの代わりにメッセージを送って動作するオブジェクト

– メッセージを管理するためのメールボックスを持つ• メッセージドリブン方式

– メールボックスを定期的に確認し、先頭にあるメッセージが実行できるものだった場合、実行する

• 非同期処理– メッセージのやりとりは非同期に行う

8

Actor

Mailbox

message Actor

Mailbox

Programmer

messageexecute execute

Working with Konoha

アクターの持つ性質• ユニークで変更不可能な名前• 変更可能な local state• メッセージ管理をするためのメールボックス• メッセージの種類

– 他のアクターに影響を及ぼすもの– アクターを生成するもの

9

Methods

Local State

Thread

MailboxActor

create

message

Working with Konoha

アクターモデルのメリット• JVM 上で実装された様々なアクターモデルを調査した結

果、アクターモデルがプログラマに対し提供しているメリットは次のようなものがある

– Encapsulation• Encapsulation State• Sage Messaging

– Fair scheduling– Location transparency– Mobility

10

Working with Konoha

Encapsulation• State Encapsulation

– 他のアクターから自身が持つ local state に直接アクセスできないようにするために、メッセージは必ずメソッドを介して処理される

• Safe Message Passing– メソッドの中にクリティカルセクションになるような

箇所がある場合は、アクターのコピーを行って、データの競合を避ける

11

Working with Konoha

Fair Scheduling• メールボックスはキュー構造をとっており、メールボッ

クス内にメッセージが入っている場合は、先頭から順に実行していく

• 現在実行されているメッセージが busy 状態の場合は次に実行されるはずのメッセージが実行されない– infinite loop, blocked on an I/O, system call

• メッセージに対応したスレッドを作ることで回避する

12

1message 2

先頭

Working with Konoha

Location Transparency• 現在それぞれのアクターがどの場所にいるかを気にせず

にプログラムが書ける– e.g.) 同一コア上、同一 CPU 上、ネットワークに繋が

れた別のノード上– アクターの名前を指定することにより、どの場所にい

るアクターとも通信できる– この機能は実行時の別ノードに対する migration や

mobility をサポートしている

13

actor = find_actor(actor_name)

ユニークに決まっているアクターの名前

アクターのアドレスが返ってくる

Working with Konoha

Mobility• アクターの処理を、異なるノードをまたいで行うことが

できる• Weak Mobility

– メールボックスが空のアクターを Migration すること• Strong Mobility

– メールボックスにメッセージが入っているアクターをMigration すること

14

Network

Actor

Working with Konoha

JVM 上のアクターモデルの比較• 実行速度の効率化のために、先に挙げたアクターモデル

のメリットをサポートしていないモデルがある

15

SALS

A

JavAc

tJet

lang

Acto

r Ar

chite

cture

Acto

rFou

ndr

y

State Encapsulation Safe Message Passing

Acto

r Ar

chite

cture

Acto

rFou

ndr

y

Scala

Ac

tors

Fair scheduling

SALS

AAc

tor

Arch

itectu

reAc

torF

ound

ry

Location transparency

SALS

A

JavAc

tJet

lang

Acto

r Ar

chite

cture

Acto

rFou

ndr

y

SALS

A

JavAc

t

Acto

r Ar

chite

cture

Acto

rFou

ndr

y

Mobility

Working with Konoha

性能評価• Threadringベンチマークを用いて、それぞれのモデルの

速度比較を行った– Actor Foundry ・ SALSA ・ Actor Architecture で遅延がみられた

Encapsulation と Fair scheduling を共に実装しているアクターモデルで遅延

が見られた

アクターのコピーに要するコストや、 thread 複製の

コストが影響している16

Working with Konoha

まとめ• アクターモデルは、並列プログラミングを安全かつ容易

に記述するため、以下の４つの機能を提供している– Encapsulation– Fair scheduling– Location transparency– Mobility

• 全ての機能をサポートしたアクターモデルは、未サポートのアクターモデルに比べてパフォーマンスが低下した– Encapsulation を行うためのアクターの複製や、 Fair

scheduling のための thread の複製を行っているのがボトルネックになっている

17

Working with Konoha

Stage: Python with Actors• 背景

– アプリケーションの性能を向上させるために、複数のノードを用いた並列計算も視野に入れて考えなければならない

• 提案– アクターモデルを、動的型付けなスクリプティング言

語である Python に用いた、 Stage を提案• Python のオブジェクト指向プログラミングはその

ままに、メソッド呼び出しの代わりに非同期メッセージを用いて動作する

18

Working with Konoha

Stage の概要• 複数のアクターを含む Theatre を持つ

– それぞれのノードにある全てのアクターの管理を行う– Theatre は各ノードに１つずつ存在する

• Network に繋がれた他のノードのアクターと通信する場合には、 Theatre を介して行う

19

Stage Communication Layer

Network

Location

ServiceMessagi

ng

Migration

Stage Python

MetaHook

sExecuting

ActorsStage

CommunicationLayer

Stage Execution Environment(Theatre)

Working with Konoha

Stage の特徴• Theatre は各ノードをつなぐインターフェースとなり、

Location transparency や Mobility の実装をサポートしている– どのアクターがどのノードにいるかは全て Theatre が把握している

20

Network

StageProgrammer

Actor Script

Theatre A

Theatre B Theatre D

Theatre C

LocalTheatre

ActorsLocation

transparency

Mobility

Working with Konoha

Stage の特徴• Python にバインドされている外部のライブラリを

Theatre 上で扱うために、 Driver Actors というレイヤーを用意している

21

GTK+Library

C 言語

アクターを操作

GTK+Library

C 言語

Theatre

PyGTK API

STAGE

bind

Actors

××

TheatreActors

Driver

Actors

PyGTK+

Actor

PyGTK+Actors

○

○

Working with Konoha

性能評価• Trapezoidal approximationベンチマークを用いた

Python と Stage(one actor), Stage(two actors) のパフォーマンス比較

22

Python(original) に対し、 Stage(one actor) の場

合で同程度の性能、 Stage(two actors) の場合で約 2 倍の性能向上が

みられた

Running on an i686 Intel Core2 CPU 2.13GHz and a 2.6 Linux Kernel

Working with Konoha

まとめ• Stage の特徴

– スクリプティング言語の文法を崩さずにアクターモデルを導入している

– 他のノードのアクターにアクセスする際に、内部ではTheatre を介して行うように実装されている

• Location transparency や Mobility の実装をサポートしている

– バインドした外部のライブラリに対してもアクターモデルを適用できるように、 Driver Actors レイヤーを実装している

• アクターモデルを実装しているが、性能の低下は見られず、扱うアクターを増やせば Python の性能を上回っている

23

Working with Konoha

Writing Concurrent Desktop Application in an Actor-Based Programming Model

• 問題– GUI アプリケーションを開発する際、 thread-safe に設計・実装することは難しい

• それぞれのコンポーネントが互いに依存し合っている

• 提案– アクターモデルを発展させた、 CoBox モデルを用い

た GUI アプリケーションの設計・実装法を提案• CoBox モデルを Java 言語の拡張として導入した言

語、JCoBox を用いて開発する

24

Working with Konoha

CoBox モデル• アクターモデルで考えられていなかった、メッセージの

スケジュール管理を導入– アクターモデルでは、アクターからのメッセージを待っている間は、次のメッセージを実行できなかった

• オブジェクト指向言語に対応するため、複数のオブジェクトをまとめて CoBox単位で管理する方法をとっている

25

Working with Konoha

CoBox の構造• オブジェクトの種類

– standard– transfer– immutable

• タスクの種類– active– ready– suspend

• リファレンスの種類– local reference– far reference

26

Working with Konoha

CoBox 内のオブジェクト• standard object

– immutable object のメソッド、フィールド変数にダイレクトにアクセスできる

– far reference を用いて別の CoBox 内のオブジェクトにアクセスできる

• transfer object– CoBox間でデータの受け渡しを行いたいときに使用す

るオブジェクト• immutable object

– 複数のコンポーネントで管理したいメソッド、フィールドを持つ、変更不可能なオブジェクト

– すべての CoBox から、 standard object による local reference を用いて参照可能

27

Working with Konoha

CoBox 内のタスク• active task

– 現在実行中のタスク• ready task

– キュー構造をとっている ready queue に入っている、実行待ち状態のタスク

• suspend task– suspend メソッドによって呼び出され、実行中のタス

クを一時停止し、再び実行できる条件がそろうまで、専用の領域で待機させられるタスク

28

Working with Konoha

CoBox のタスク管理• task の生成

– CoBox 内のオブジェクトがメソッド呼び出しをした際に作られる

• task の実行– active な task により実際のメソッド呼び出しやフィー

ルドへのアクセスが行われる• task の中断や一時停止

– ready task( 処理の中断やタイムアウト時）• ready queue の最後に task を移す

– suspend task（処理が一時停止した場合）• suspend task を格納する領域に移され、条件がそろったら起動する

29

Working with Konoha

CoBox のスケジューリング• Fair scheduling では、メッセージ毎に thread を立てて、

busy ループのあるメッセージの対処をしていた– スケールしたときに、大量のメッセージの数だけ

thread もたってしまい、 thread 複製コストが大きい– busy ループを含んだ thread が破棄されずに残ってし

まう

• CoBox のスケジューリング方法では、タイムアウトや処理の中断・停止・一時停止などに対しタスク管理が行われるため、 Fair scheduling での問題点を防ぐことができる

30

Working with Konoha

JCoBox• Java 言語の拡張として、 CoBox モデルを取り入れた言

語– オブジェクト指向で記述できる Java の文法を崩さず

に、 CoBox モデルを利用できる

– @CoBox や @Immutable, @Transfer といった修飾子をクラスの宣言時に付けることで、 CoBox の作成や各種オブジェクトの作成を行うことができる

– メソッドの呼び出し方法は、「 . 」の代わりに「 ! 」を使う

31

Working with Konoha

JCoBox を用いた Application例• Concurrent Music Manager を実装

– 各コンポーネントを CoBox単位で管理し、コンポーネント間のやりとりを CoBox を介して行うことで、プログラマがロック処理やタスク管理などを気にせず並列プログラミングを記述することができる

32

Working with Konoha

まとめ• CoBox モデルを用いた言語、 JCoBox を用いて実際にデ

スクトップアプリケーションを実装– thread-model で開発する場合と比較し、ロック処理や

デッドロック、タスク管理などを考えなくてよい

– オブジェクト指向での開発を妨げることなく、並列計算モデルを扱うことができる

33

Working with Konoha

全体のまとめと今後• これからの時代はマルチコアを活かしたソフトウェア開

発が求められており、並列プログラミングをサポートするための並列計算モデルについて調査した– アクターモデル– CoBox モデル

• 今後は、更に並列計算モデルの調査をし、研究室で開発しているプログラミング言語 Konoha に並列プログラミングをサポートするための新しい並列計算モデルを組み込みたい

34