slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
プログラミング言語 分散並列実行に関する研究調査 PowerPoint Presentation
Download Presentation
プログラミング言語 分散並列実行に関する研究調査

Loading in 2 Seconds...

play fullscreen
1 / 34

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


  • 122 Views
  • Uploaded on

プログラミング言語 分散並列実行に関する研究調査. 横浜国立大学 大学院 工学府 10GD131 五嶋 壮晃 10/08/02 論文レビュー発表会. CPU クロック速度の限界. ムーアの法則 「半導体チップに集積されるトランジスターの数は約 2 年ごとに倍増する」という法則 それに伴い CPU クロック速度も向上すると考えられている 近年のチップ速度の限界は 3.5GHz 程度にとどまっている. マルチコアの時代. ムーアの法則は、マルチコアの領域では達成できており、 CPU に搭載されるコア数は年々増加している

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'プログラミング言語 分散並列実行に関する研究調査' - salma


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

横浜国立大学大学院工学府

10GD131 五嶋 壮晃

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

slide2
CPUクロック速度の限界
  • ムーアの法則
    • 「半導体チップに集積されるトランジスターの数は約 2 年ごとに倍増する」という法則
    • それに伴いCPUクロック速度も向上すると考えられている
  • 近年のチップ速度の限界は3.5GHz程度にとどまっている
slide3
マルチコアの時代
  • ムーアの法則は、マルチコアの領域では達成できており、CPUに搭載されるコア数は年々増加している
    • 現在24coresのCPUが登場し、2012年には48coresのCPUが登場すると言われている
  • これからのソフトウェア・アプリケーション開発は、マルチコアを活かすことでパフォーマンスを向上していく必要がある
slide4
並列プログラミング
  • マルチコアを活かすために、大きく分けて次の2通りのプログラミング方法がある
    • マルチスレッドプログラミング
    • マルチプロセスプログラミング
  • マルチプロセスプログラミングは、プロセス複製のコストが大きいため、コア数を増やしても性能向上させることが難しい
  • マルチスレッドプログラミングは、共有メモリを用いているためにロック処理や非決定性を考慮しなければならならい
slide5
並列計算モデル

Actor Model

CoBox Model

Concurrent Computing Model

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

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

actor frameworks for the jvm platform a comparative analysis
Actor Frameworks for the JVM Platform:A Comparative Analysis

SALSA

Actor Architecture

Kilim

Jetlang

ActorFoundry

JavAct

Scala Actors

Actor Model on JVM

  • 背景
    • マルチコアを活かしたプログラミングをする上でアクターモデルが注目を集めている
  • 目的
    • JVM上でアクターモデルを実装した言語・Frameworkを分析し、アクターモデルの特徴や性能の違いを示す
slide8
アクターモデル

execute

execute

Actor

Actor

message

message

Mailbox

Mailbox

Programmer

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

Local State

Thread

Methods

Actor

Mailbox

create

message

  • ユニークで変更不可能な名前
  • 変更可能なlocal state
  • メッセージ管理をするためのメールボックス
  • メッセージの種類
    • 他のアクターに影響を及ぼすもの
    • アクターを生成するもの
slide10
アクターモデルのメリット
  • JVM上で実装された様々なアクターモデルを調査した結果、アクターモデルがプログラマに対し提供しているメリットは次のようなものがある
    • Encapsulation
      • Encapsulation State
      • Sage Messaging
    • Fair scheduling
    • Location transparency
    • Mobility
encapsulation
Encapsulation
  • State Encapsulation
    • 他のアクターから自身が持つlocal stateに直接アクセスできないようにするために、メッセージは必ずメソッドを介して処理される
  • Safe Message Passing
    • メソッドの中にクリティカルセクションになるような箇所がある場合は、アクターのコピーを行って、データの競合を避ける
fair scheduling
Fair Scheduling

1

2

message

先頭

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

ユニークに決まって

いるアクターの名前

actor = find_actor(actor_name)

アクターのアドレス

が返ってくる

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

Actor

Network

  • アクターの処理を、異なるノードをまたいで行うことができる
  • Weak Mobility
    • メールボックスが空のアクターをMigrationすること
  • Strong Mobility
    • メールボックスにメッセージが入っているアクターをMigrationすること
slide15
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

実行速度の効率化のために、先に挙げたアクターモデルのメリットをサポートしていないモデルがある

slide16
性能評価

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

アクターのコピーに要するコストや、thread複製のコストが影響している

  • Threadringベンチマークを用いて、それぞれのモデルの速度比較を行った
    • Actor Foundry・SALSA・Actor Architectureで遅延がみられた
slide17
まとめ
  • アクターモデルは、並列プログラミングを安全かつ容易に記述するため、以下の4つの機能を提供している
    • Encapsulation
    • Fair scheduling
    • Location transparency
    • Mobility
  • 全ての機能をサポートしたアクターモデルは、未サポートのアクターモデルに比べてパフォーマンスが低下した
    • Encapsulationを行うためのアクターの複製や、Fair schedulingのためのthreadの複製を行っているのがボトルネックになっている
stage python with actors
Stage: Python with Actors
  • 背景
    • アプリケーションの性能を向上させるために、複数のノードを用いた並列計算も視野に入れて考えなければならない
  • 提案
    • アクターモデルを、動的型付けなスクリプティング言語であるPythonに用いた、Stageを提案
      • Pythonのオブジェクト指向プログラミングはそのままに、メソッド呼び出しの代わりに非同期メッセージを用いて動作する
stage
Stageの概要

Stage Python

Location Service

Executing

Actors

Meta

Hooks

Network

Messaging

Stage

Communication

Layer

Stage

Communication

Layer

Migration

Stage Execution Environment(Theatre)

  • 複数のアクターを含むTheatreを持つ
    • それぞれのノードにある全てのアクターの管理を行う
    • Theatreは各ノードに1つずつ存在する
  • Networkに繋がれた他のノードのアクターと通信する場合には、Theatreを介して行う
stage1
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が把握している
stage2
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

slide22
性能評価

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)のパフォーマンス比較

slide23
まとめ
  • Stageの特徴
    • スクリプティング言語の文法を崩さずにアクターモデルを導入している
    • 他のノードのアクターにアクセスする際に、内部ではTheatreを介して行うように実装されている
      • Location transparencyやMobilityの実装をサポートしている
    • バインドした外部のライブラリに対してもアクターモデルを適用できるように、Driver Actorsレイヤーを実装している
  • アクターモデルを実装しているが、性能の低下は見られず、扱うアクターを増やせばPythonの性能を上回っている
writing concurrent desktop application in an actor based programming model
Writing Concurrent Desktop Application in an Actor-Based Programming Model
  • 問題
    • GUIアプリケーションを開発する際、thread-safeに設計・実装することは難しい
      • それぞれのコンポーネントが互いに依存し合っている
  • 提案
    • アクターモデルを発展させた、CoBoxモデルを用いたGUIアプリケーションの設計・実装法を提案
      • CoBoxモデルをJava言語の拡張として導入した言語、JCoBoxを用いて開発する
cobox
CoBoxモデル
  • アクターモデルで考えられていなかった、メッセージのスケジュール管理を導入
    • アクターモデルでは、アクターからのメッセージを待っている間は、次のメッセージを実行できなかった
  • オブジェクト指向言語に対応するため、複数のオブジェクトをまとめてCoBox単位で管理する方法をとっている
cobox1
CoBoxの構造
  • オブジェクトの種類
    • standard
    • transfer
    • immutable
  • タスクの種類
    • active
    • ready
    • suspend
  • リファレンスの種類
    • local reference
    • far reference
cobox2
CoBox内のオブジェクト
  • standard object
    • immutable objectのメソッド、フィールド変数にダイレクトにアクセスできる
    • far referenceを用いて別のCoBox内のオブジェクトにアクセスできる
  • transfer object
    • CoBox間でデータの受け渡しを行いたいときに使用するオブジェクト
  • immutable object
    • 複数のコンポーネントで管理したいメソッド、フィールドを持つ、変更不可能なオブジェクト
    • すべてのCoBoxから、standard objectによるlocal referenceを用いて参照可能
cobox3
CoBox内のタスク
  • active task
    • 現在実行中のタスク
  • ready task
    • キュー構造をとっているready queueに入っている、実行待ち状態のタスク
  • suspend task
    • suspendメソッドによって呼び出され、実行中のタスクを一時停止し、再び実行できる条件がそろうまで、専用の領域で待機させられるタスク
cobox4
CoBoxのタスク管理
  • taskの生成
    • CoBox内のオブジェクトがメソッド呼び出しをした際に作られる
  • taskの実行
    • activeなtaskにより実際のメソッド呼び出しやフィールドへのアクセスが行われる
  • taskの中断や一時停止
    • ready task(処理の中断やタイムアウト時)
      • ready queueの最後にtaskを移す
    • suspend task(処理が一時停止した場合)
      • suspend taskを格納する領域に移され、条件がそろったら起動する
cobox5
CoBoxのスケジューリング
  • Fair schedulingでは、メッセージ毎にthreadを立てて、busyループのあるメッセージの対処をしていた
    • スケールしたときに、大量のメッセージの数だけthreadもたってしまい、thread複製コストが大きい
    • busyループを含んだthreadが破棄されずに残ってしまう
  • CoBoxのスケジューリング方法では、タイムアウトや処理の中断・停止・一時停止などに対しタスク管理が行われるため、Fair schedulingでの問題点を防ぐことができる
jcobox
JCoBox
  • Java言語の拡張として、CoBoxモデルを取り入れた言語
    • オブジェクト指向で記述できるJavaの文法を崩さずに、CoBoxモデルを利用できる
    • @CoBoxや@Immutable, @Transferといった修飾子をクラスの宣言時に付けることで、CoBoxの作成や各種オブジェクトの作成を行うことができる
    • メソッドの呼び出し方法は、「.」の代わりに「!」を使う
jcobox application
JCoBoxを用いたApplication例
  • Concurrent Music Managerを実装
    • 各コンポーネントをCoBox単位で管理し、コンポーネント間のやりとりをCoBoxを介して行うことで、プログラマがロック処理やタスク管理などを気にせず並列プログラミングを記述することができる
slide33
まとめ
  • CoBoxモデルを用いた言語、JCoBoxを用いて実際にデスクトップアプリケーションを実装
    • thread-modelで開発する場合と比較し、ロック処理やデッドロック、タスク管理などを考えなくてよい
    • オブジェクト指向での開発を妨げることなく、並列計算モデルを扱うことができる
slide34
全体のまとめと今後
  • これからの時代はマルチコアを活かしたソフトウェア開発が求められており、並列プログラミングをサポートするための並列計算モデルについて調査した
    • アクターモデル
    • CoBoxモデル
  • 今後は、更に並列計算モデルの調査をし、研究室で開発しているプログラミング言語Konohaに並列プログラミングをサポートするための新しい並列計算モデルを組み込みたい