Transcript Konoha
Working with Konoha プログラミング言語 分散並列実行に関する研究調査 横浜国立大学大学院工学府 10GD131 五嶋 壮晃 10/08/02 論文レビュー発表会 Working with Konoha CPUクロック速度の限界 • ムーアの法則 – 「半導体チップに集積されるトランジスターの数は約 2 年ごとに倍増する」という法則 – それに伴いCPUクロック速度も向上すると考えられて いる • 近年のチップ速度の限界は3.5GHz程度にとどまっている 1 Working with Konoha マルチコアの時代 • ムーアの法則は、マルチコアの領域では達成できており、 CPUに搭載されるコア数は年々増加している – 現在24coresのCPUが登場し、2012年には48coresの CPUが登場すると言われている • これからのソフトウェア・アプリケーション開発は、マ ルチコアを活かすことでパフォーマンスを向上していく 必要がある 2 Working with Konoha 並列プログラミング • マルチコアを活かすために、大きく分けて次の２通りの プログラミング方法がある – マルチスレッドプログラミング – マルチプロセスプログラミング • マルチプロセスプログラミングは、プロセス複製のコス トが大きいため、コア数を増やしても性能向上させるこ とが難しい • マルチスレッドプログラミングは、共有メモリを用いて いるためにロック処理や非決定性を考慮しなければなら ならい 3 Working with Konoha 並列計算モデル • 並列プログラミングをプログラマが安全かつ容易に記述 できるようにモデル化したもの – 今回は並列ソフトウェア開発のために多くのユーザが 用いている、Java言語を扱ったモデルについて調査し た • アクターモデル • CoBoxモデル Actor Model CoBox Model Concurrent Computing Model 4 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 5 Working with Konoha Actor Frameworks for the JVM Platform: A Comparative Analysis • 背景 – マルチコアを活かしたプログラミングをする上でアク ターモデルが注目を集めている • 目的 – JVM上でアクターモデルを実装した言語・Framework を分析し、アクターモデルの特徴や性能の違いを示す Actor Model on JVM 6 Working with Konoha アクターモデル • アクター – メソッド呼び出しの代わりにメッセージを送って動作 するオブジェクト – メッセージを管理するためのメールボックスを持つ • メッセージドリブン方式 – メールボックスを定期的に確認し、先頭にあるメッ セージが実行できるものだった場合、実行する • 非同期処理 – メッセージのやりとりは非同期に行う message execute message Actor Mailbox Programmer execute Actor Mailbox 7 Working with Konoha アクターの持つ性質 • • • • ユニークで変更不可能な名前 変更可能なlocal state メッセージ管理をするためのメールボックス メッセージの種類 – 他のアクターに影響を及ぼすもの – アクターを生成するもの Local State create Thread Methods message Mailbox 8 Working with Konoha アクターモデルのメリット • JVM上で実装された様々なアクターモデルを調査した結 果、アクターモデルがプログラマに対し提供しているメ リットは次のようなものがある – Encapsulation • Encapsulation State • Sage Messaging – Fair scheduling – Location transparency – Mobility 9 Working with Konoha Encapsulation • State Encapsulation – 他のアクターから自身が持つlocal stateに直接アクセス できないようにするために、メッセージは必ずメソッ ドを介して処理される • Safe Message Passing – メソッドの中にクリティカルセクションになるような 箇所がある場合は、アクターのコピーを行って、デー タの競合を避ける 10 Working with Konoha Fair Scheduling • メールボックスはキュー構造をとっており、メールボッ クス内にメッセージが入っている場合は、先頭から順に 実行していく • 現在実行されているメッセージがbusy状態の場合は次に 実行されるはずのメッセージが実行されない – infinite loop, blocked on an I/O, system call • メッセージに対応したスレッドを作ることで回避する message 先頭 1 2 11 Working with Konoha Location Transparency • 現在それぞれのアクターがどの場所にいるかを気にせず にプログラムが書ける – e.g.) 同一コア上、同一CPU上、ネットワークに繋がれ た別のノード上 – アクターの名前を指定することにより、どの場所にい るアクターとも通信できる – この機能は実行時の別ノードに対するmigrationや mobilityをサポートしている ユニークに決まって いるアクターの名前 actor = find_actor(actor_name) アクターのアドレス が返ってくる 12 Working with Konoha Mobility • アクターの処理を、異なるノードをまたいで行うことが できる • Weak Mobility – メールボックスが空のアクターをMigrationすること • Strong Mobility – メールボックスにメッセージが入っているアクターを Migrationすること Actor Network 13 Working with Konoha JVM上のアクターモデルの比較 • 実行速度の効率化のために、先に挙げたアクターモデル のメリットをサポートしていないモデルがある State Encapsulation Safe Message Passing Fair scheduling Location transparency Mobility 14 Working with Konoha 性能評価 • Threadringベンチマークを用いて、それぞれのモデルの 速度比較を行った – Actor Foundry・SALSA・Actor Architectureで遅延がみ られた EncapsulationとFair schedulingを共に実装してい るアクターモデルで遅延が 見られた アクターのコピーに要する コストや、thread複製の コストが影響している 15 Working with Konoha まとめ • アクターモデルは、並列プログラミングを安全かつ容易 に記述するため、以下の４つの機能を提供している – Encapsulation – Fair scheduling – Location transparency – Mobility • 全ての機能をサポートしたアクターモデルは、未サポー トのアクターモデルに比べてパフォーマンスが低下した – Encapsulationを行うためのアクターの複製や、Fair schedulingのためのthreadの複製を行っているのがボト ルネックになっている 16 Working with Konoha Stage: Python with Actors • 背景 – アプリケーションの性能を向上させるために、複数の ノードを用いた並列計算も視野に入れて考えなければ ならない • 提案 – アクターモデルを、動的型付けなスクリプティング言 語であるPythonに用いた、Stageを提案 • Pythonのオブジェクト指向プログラミングはそのま まに、メソッド呼び出しの代わりに非同期メッセー ジを用いて動作する 17 Working with Konoha Stageの概要 • 複数のアクターを含むTheatreを持つ – それぞれのノードにある全てのアクターの管理を行う – Theatreは各ノードに１つずつ存在する • Networkに繋がれた他のノードのアクターと通信する場 合には、Theatreを介して行う Location Service Network Messaging Stage Communication Layer StageStage Executing Meta Actors Hooks PythonCommunication Layer Migration Stage Execution Environment(Theatre) 18 Working with Konoha Stageの特徴 • Theatreは各ノードをつなぐインターフェースとなり、 Location transparencyやMobilityの実装をサポートして いる – どのアクターがどのノードにいるかは全てTheatreが把 握している Location Actors transparency Theatre C Theatre A Actor Script Local Theatre Stage Programmer Network Mobility Theatre B Theatre D 19 Working with Konoha Stageの特徴 • Pythonにバインドされている外部のライブラリを Theatre上で扱うために、Driver Actorsというレイヤーを 用意している ○ Actors アクターを操作 Theatre ×× GTK+ Library bind PyGTK API ○ C言語 PyGTK+ Actors Actors Theatre PyGTK+ Actor Driver Actor s GTK+ Library C言語 STAGE 20 Working with Konoha 性能評価 • Trapezoidal approximationベンチマークを用いた PythonとStage(one actor), Stage(two actors)の パフォーマンス比較 Python(original)に対し、 Stage(one actor)の場合で同 程度の性能、Stage(two actors)の場合で約2倍の性能 向上がみられた Running on an i686 Intel Core2 CPU 2.13GHz and a 2.6 Linux Kernel 21 Working with Konoha まとめ • Stageの特徴 – スクリプティング言語の文法を崩さずにアクターモデ ルを導入している – 他のノードのアクターにアクセスする際に、内部では Theatreを介して行うように実装されている • Location transparencyやMobilityの実装をサポートし ている – バインドした外部のライブラリに対してもアクターモ デルを適用できるように、Driver Actorsレイヤーを実 装している • アクターモデルを実装しているが、性能の低下は見られ ず、扱うアクターを増やせばPythonの性能を上回ってい る 22 Working with Konoha Writing Concurrent Desktop Application in an Actor-Based Programming Model • 問題 – GUIアプリケーションを開発する際、thread-safeに設 計・実装することは難しい • それぞれのコンポーネントが互いに依存し合ってい る • 提案 – アクターモデルを発展させた、CoBoxモデルを用いた GUIアプリケーションの設計・実装法を提案 • CoBoxモデルをJava言語の拡張として導入した言語、 JCoBoxを用いて開発する 23 Working with Konoha CoBoxモデル • アクターモデルで考えられていなかった、メッセージの スケジュール管理を導入 – アクターモデルでは、アクターからのメッセージを 待っている間は、次のメッセージを実行できなかった • オブジェクト指向言語に対応するため、複数のオブジェ クトをまとめてCoBox単位で管理する方法をとっている 24 Working with Konoha CoBoxの構造 • オブジェクトの種類 – standard – transfer – immutable • タスクの種類 – active – ready – suspend • リファレンスの種類 – local reference – far reference 25 Working with Konoha CoBox内のオブジェクト • standard object – immutable objectのメソッド、フィールド変数にダイレ クトにアクセスできる – far referenceを用いて別のCoBox内のオブジェクトにア クセスできる • transfer object – CoBox間でデータの受け渡しを行いたいときに使用す るオブジェクト • immutable object – 複数のコンポーネントで管理したいメソッド、フィー ルドを持つ、変更不可能なオブジェクト – すべてのCoBoxから、standard objectによるlocal referenceを用いて参照可能 26 Working with Konoha CoBox内のタスク • active task – 現在実行中のタスク • ready task – キュー構造をとっているready queueに入っている、実 行待ち状態のタスク • suspend task – suspendメソッドによって呼び出され、実行中のタス クを一時停止し、再び実行できる条件がそろうまで、 専用の領域で待機させられるタスク 27 Working with Konoha CoBoxのタスク管理 • taskの生成 – CoBox内のオブジェクトがメソッド呼び出しをした際 に作られる • taskの実行 – activeなtaskにより実際のメソッド呼び出しやフィール ドへのアクセスが行われる • taskの中断や一時停止 – ready task(処理の中断やタイムアウト時） • ready queueの最後にtaskを移す – suspend task（処理が一時停止した場合） • suspend taskを格納する領域に移され、条件がそ ろったら起動する 28 Working with Konoha CoBoxのスケジューリング • Fair schedulingでは、メッセージ毎にthreadを立てて、 busyループのあるメッセージの対処をしていた – スケールしたときに、大量のメッセージの数だけ threadもたってしまい、thread複製コストが大きい – busyループを含んだthreadが破棄されずに残ってしま う • CoBoxのスケジューリング方法では、タイムアウトや処 理の中断・停止・一時停止などに対しタスク管理が行わ れるため、Fair schedulingでの問題点を防ぐことができ る 29 Working with Konoha JCoBox • Java言語の拡張として、CoBoxモデルを取り入れた言語 – オブジェクト指向で記述できるJavaの文法を崩さずに、 CoBoxモデルを利用できる – @CoBoxや@Immutable, @Transferといった修飾子を クラスの宣言時に付けることで、CoBoxの作成や各種 オブジェクトの作成を行うことができる – メソッドの呼び出し方法は、「.」の代わりに「!」を使 う 30 Working with Konoha JCoBoxを用いたApplication例 • Concurrent Music Managerを実装 – 各コンポーネントをCoBox単位で管理し、コンポーネ ント間のやりとりをCoBoxを介して行うことで、プロ グラマがロック処理やタスク管理などを気にせず並列 プログラミングを記述することができる 31 Working with Konoha まとめ • CoBoxモデルを用いた言語、JCoBoxを用いて実際にデ スクトップアプリケーションを実装 – thread-modelで開発する場合と比較し、ロック処理や デッドロック、タスク管理などを考えなくてよい – オブジェクト指向での開発を妨げることなく、並列計 算モデルを扱うことができる 32 Working with Konoha 全体のまとめと今後 • これからの時代はマルチコアを活かしたソフトウェア開 発が求められており、並列プログラミングをサポートす るための並列計算モデルについて調査した – アクターモデル – CoBoxモデル • 今後は、更に並列計算モデルの調査をし、研究室で開発 しているプログラミング言語Konohaに並列プログラミン グをサポートするための新しい並列計算モデルを組み込 みたい 33