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

1. プログラミング言語分散並列実行に関する研究調査プログラミング言語分散並列実行に関する研究調査 横浜国立大学大学院工学府 10GD131 五嶋　壮晃 10/08/02 論文レビュー発表会

2. CPUクロック速度の限界 • ムーアの法則 • 「半導体チップに集積されるトランジスターの数は約 2 年ごとに倍増する」という法則 • それに伴いCPUクロック速度も向上すると考えられている • 近年のチップ速度の限界は3.5GHz程度にとどまっている

3. マルチコアの時代 • ムーアの法則は、マルチコアの領域では達成できており、CPUに搭載されるコア数は年々増加している • 現在24coresのCPUが登場し、2012年には48coresのCPUが登場すると言われている • これからのソフトウェア・アプリケーション開発は、マルチコアを活かすことでパフォーマンスを向上していく必要がある

4. 並列プログラミング • マルチコアを活かすために、大きく分けて次の２通りのプログラミング方法がある • マルチスレッドプログラミング • マルチプロセスプログラミング • マルチプロセスプログラミングは、プロセス複製のコストが大きいため、コア数を増やしても性能向上させることが難しい • マルチスレッドプログラミングは、共有メモリを用いているためにロック処理や非決定性を考慮しなければならならい

5. 並列計算モデル Actor Model CoBox Model Concurrent Computing Model • 並列プログラミングをプログラマが安全かつ容易に記述できるようにモデル化したもの • 今回は並列ソフトウェア開発のために多くのユーザが用いている、Java言語を扱ったモデルについて調査した • アクターモデル • CoBoxモデル

6. 論文のリスト 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

7. Actor Frameworks for the JVM Platform:A Comparative Analysis SALSA Actor Architecture Kilim Jetlang ActorFoundry JavAct Scala Actors Actor Model on JVM • 背景 • マルチコアを活かしたプログラミングをする上でアクターモデルが注目を集めている • 目的 • JVM上でアクターモデルを実装した言語・Frameworkを分析し、アクターモデルの特徴や性能の違いを示す

8. アクターモデル execute execute Actor Actor message message Mailbox Mailbox Programmer • アクター • メソッド呼び出しの代わりにメッセージを送って動作するオブジェクト • メッセージを管理するためのメールボックスを持つ • メッセージドリブン方式 • メールボックスを定期的に確認し、先頭にあるメッセージが実行できるものだった場合、実行する • 非同期処理 • メッセージのやりとりは非同期に行う

9. アクターの持つ性質 Local State Thread Methods Actor Mailbox create message • ユニークで変更不可能な名前 • 変更可能なlocal state • メッセージ管理をするためのメールボックス • メッセージの種類 • 他のアクターに影響を及ぼすもの • アクターを生成するもの

10. アクターモデルのメリット • JVM上で実装された様々なアクターモデルを調査した結果、アクターモデルがプログラマに対し提供しているメリットは次のようなものがある • Encapsulation • Encapsulation State • Sage Messaging • Fair scheduling • Location transparency • Mobility

11. Encapsulation • State Encapsulation • 他のアクターから自身が持つlocal stateに直接アクセスできないようにするために、メッセージは必ずメソッドを介して処理される • Safe Message Passing • メソッドの中にクリティカルセクションになるような箇所がある場合は、アクターのコピーを行って、データの競合を避ける

12. Fair Scheduling 1 2 message 先頭 • メールボックスはキュー構造をとっており、メールボックス内にメッセージが入っている場合は、先頭から順に実行していく • 現在実行されているメッセージがbusy状態の場合は次に実行されるはずのメッセージが実行されない • infinite loop, blocked on an I/O, system call • メッセージに対応したスレッドを作ることで回避する

13. Location Transparency ユニークに決まって いるアクターの名前 actor = find_actor(actor_name) アクターのアドレス が返ってくる • 現在それぞれのアクターがどの場所にいるかを気にせずにプログラムが書ける • e.g.) 同一コア上、同一CPU上、ネットワークに繋がれた別のノード上 • アクターの名前を指定することにより、どの場所にいるアクターとも通信できる • この機能は実行時の別ノードに対するmigrationやmobilityをサポートしている

14. Mobility Actor Network • アクターの処理を、異なるノードをまたいで行うことができる • Weak Mobility • メールボックスが空のアクターをMigrationすること • Strong Mobility • メールボックスにメッセージが入っているアクターをMigrationすること

15. JVM上のアクターモデルの比較 Actor Architecture Jetlang SALSA ActorFoundry JavAct Actor Architecture ActorFoundry State Encapsulation Safe Message Passing SALSA Actor Architecture Scala Actors ActorFoundry Fair scheduling Actor Architecture Actor Architecture Jetlang SALSA ActorFoundry JavAct SALSA ActorFoundry JavAct Location transparency Mobility 実行速度の効率化のために、先に挙げたアクターモデルのメリットをサポートしていないモデルがある

16. 性能評価 EncapsulationとFair schedulingを共に実装しているアクターモデルで遅延が見られた アクターのコピーに要するコストや、thread複製のコストが影響している • Threadringベンチマークを用いて、それぞれのモデルの速度比較を行った • Actor Foundry・SALSA・Actor Architectureで遅延がみられた

17. まとめ • アクターモデルは、並列プログラミングを安全かつ容易に記述するため、以下の４つの機能を提供している • Encapsulation • Fair scheduling • Location transparency • Mobility • 全ての機能をサポートしたアクターモデルは、未サポートのアクターモデルに比べてパフォーマンスが低下した • Encapsulationを行うためのアクターの複製や、Fair schedulingのためのthreadの複製を行っているのがボトルネックになっている

18. Stage: Python with Actors • 背景 • アプリケーションの性能を向上させるために、複数のノードを用いた並列計算も視野に入れて考えなければならない • 提案 • アクターモデルを、動的型付けなスクリプティング言語であるPythonに用いた、Stageを提案 • Pythonのオブジェクト指向プログラミングはそのままに、メソッド呼び出しの代わりに非同期メッセージを用いて動作する

19. Stageの概要 Stage Python Location Service Executing Actors Meta Hooks Network Messaging Stage Communication Layer Stage Communication Layer Migration Stage Execution Environment(Theatre) • 複数のアクターを含むTheatreを持つ • それぞれのノードにある全てのアクターの管理を行う • Theatreは各ノードに１つずつ存在する • Networkに繋がれた他のノードのアクターと通信する場合には、Theatreを介して行う

20. Stageの特徴 Location transparency Actors Theatre C Theatre A Actor Script Network Local Theatre Stage Programmer Mobility Theatre B Theatre D • Theatreは各ノードをつなぐインターフェースとなり、Location transparencyやMobilityの実装をサポートしている • どのアクターがどのノードにいるかは全てTheatreが把握している

21. Stageの特徴 Actors Theatre ○ アクターを操作 × C言語 × GTK+ Library PyGTK API bind ○ PyGTK+ Actors Actors Theatre C言語 GTK+ Library PyGTK+ Actor Driver Actors Pythonにバインドされている外部のライブラリをTheatre上で扱うために、Driver Actorsというレイヤーを用意している STAGE

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 Trapezoidal approximationベンチマークを用いたPythonとStage(one actor), Stage(two actors)のパフォーマンス比較

23. まとめ • Stageの特徴 • スクリプティング言語の文法を崩さずにアクターモデルを導入している • 他のノードのアクターにアクセスする際に、内部ではTheatreを介して行うように実装されている • Location transparencyやMobilityの実装をサポートしている • バインドした外部のライブラリに対してもアクターモデルを適用できるように、Driver Actorsレイヤーを実装している • アクターモデルを実装しているが、性能の低下は見られず、扱うアクターを増やせばPythonの性能を上回っている

24. Writing Concurrent Desktop Application in an Actor-Based Programming Model • 問題 • GUIアプリケーションを開発する際、thread-safeに設計・実装することは難しい • それぞれのコンポーネントが互いに依存し合っている • 提案 • アクターモデルを発展させた、CoBoxモデルを用いたGUIアプリケーションの設計・実装法を提案 • CoBoxモデルをJava言語の拡張として導入した言語、JCoBoxを用いて開発する

25. CoBoxモデル • アクターモデルで考えられていなかった、メッセージのスケジュール管理を導入 • アクターモデルでは、アクターからのメッセージを待っている間は、次のメッセージを実行できなかった • オブジェクト指向言語に対応するため、複数のオブジェクトをまとめてCoBox単位で管理する方法をとっている

26. CoBoxの構造 • オブジェクトの種類 • standard • transfer • immutable • タスクの種類 • active • ready • suspend • リファレンスの種類 • local reference • far reference

27. CoBox内のオブジェクト • standard object • immutable objectのメソッド、フィールド変数にダイレクトにアクセスできる • far referenceを用いて別のCoBox内のオブジェクトにアクセスできる • transfer object • CoBox間でデータの受け渡しを行いたいときに使用するオブジェクト • immutable object • 複数のコンポーネントで管理したいメソッド、フィールドを持つ、変更不可能なオブジェクト • すべてのCoBoxから、standard objectによるlocal referenceを用いて参照可能

28. CoBox内のタスク • active task • 現在実行中のタスク • ready task • キュー構造をとっているready queueに入っている、実行待ち状態のタスク • suspend task • suspendメソッドによって呼び出され、実行中のタスクを一時停止し、再び実行できる条件がそろうまで、専用の領域で待機させられるタスク

29. CoBoxのタスク管理 • taskの生成 • CoBox内のオブジェクトがメソッド呼び出しをした際に作られる • taskの実行 • activeなtaskにより実際のメソッド呼び出しやフィールドへのアクセスが行われる • taskの中断や一時停止 • ready task(処理の中断やタイムアウト時） • ready queueの最後にtaskを移す • suspend task（処理が一時停止した場合） • suspend taskを格納する領域に移され、条件がそろったら起動する

30. CoBoxのスケジューリング • Fair schedulingでは、メッセージ毎にthreadを立てて、busyループのあるメッセージの対処をしていた • スケールしたときに、大量のメッセージの数だけthreadもたってしまい、thread複製コストが大きい • busyループを含んだthreadが破棄されずに残ってしまう • CoBoxのスケジューリング方法では、タイムアウトや処理の中断・停止・一時停止などに対しタスク管理が行われるため、Fair schedulingでの問題点を防ぐことができる

31. JCoBox • Java言語の拡張として、CoBoxモデルを取り入れた言語 • オブジェクト指向で記述できるJavaの文法を崩さずに、CoBoxモデルを利用できる • @CoBoxや@Immutable, @Transferといった修飾子をクラスの宣言時に付けることで、CoBoxの作成や各種オブジェクトの作成を行うことができる • メソッドの呼び出し方法は、「.」の代わりに「!」を使う

32. JCoBoxを用いたApplication例 • Concurrent Music Managerを実装 • 各コンポーネントをCoBox単位で管理し、コンポーネント間のやりとりをCoBoxを介して行うことで、プログラマがロック処理やタスク管理などを気にせず並列プログラミングを記述することができる

33. まとめ • CoBoxモデルを用いた言語、JCoBoxを用いて実際にデスクトップアプリケーションを実装 • thread-modelで開発する場合と比較し、ロック処理やデッドロック、タスク管理などを考えなくてよい • オブジェクト指向での開発を妨げることなく、並列計算モデルを扱うことができる

34. 全体のまとめと今後 • これからの時代はマルチコアを活かしたソフトウェア開発が求められており、並列プログラミングをサポートするための並列計算モデルについて調査した • アクターモデル • CoBoxモデル • 今後は、更に並列計算モデルの調査をし、研究室で開発しているプログラミング言語Konohaに並列プログラミングをサポートするための新しい並列計算モデルを組み込みたい