Cloud Computing Developer Day 2009 終了

2009年9月29日 at 8:26 PM 2件のコメント



先日は、多くの皆様に下記のイベントにお越し頂き誠にありがとうございました。




Cloud Computing Developer Day 2009

〜クラウド時代に求められる新たな技術標準とは?〜




発表では、Sun Fire Tシリーズのご紹介と、Java コンカレンシー

ユーティリティについて紹介させて頂きました。

Java コンカレンシーについては Java SE 5 から利用可能になっている

という事で、既にご利用頂いている方も多くいらっしゃるかと思い、

どの位のお客様に興味を持って頂けるか発表前は不安しておりましたが、

発表後に数名のお客様からご質問等を頂き、興味を持って頂けたのではないかと

安心致しました。



発表後、お客様からの発表資料が欲しいというご要望を頂きました。

恐らく、イベントサイトにも後日同じ資料がアップされるかと思いますが、

許可を得たので、本ブログでも先日の発表資料とデモ動画を公開致します。



デモ動画については、発表中でも説明いたしましたが、本来であれば、

同じ計算量をそれぞれでどの位の時間で終了するかについて示したかったのですが、

シングルスレッドとコンカレントであまりにも差がつきすぎ、時間的な

制限もあったため、約20秒間でそれぞれどの位の処理を行えるかについて

デモで実施致しました。



コンカレンシーユーティリティを使うと CPU を有効活用できるようになります。

資源を無駄使いせず是非有効利用してください。



発表資料はこちら






PS.

カメラを持って行ってたのですが撮る余裕がなく、

イベントの写真を載せることができません。すいませんでした。



追記:(2009/10/01)

本ブログ投稿のコメントに櫻庭さんから P27 に対してコメントを頂きました。



Java SE 7 で導入される、Fork-Join のメカニズムについて

資料中で下記のように説明しております。



> 大量の計算が必要な場合、処理を分割し、分割された中で個別に

> 計算し最後に結果を集計するような場合に有効(再帰計算等)



この Fork-Join の使用用途の説明に対して下記のようにあるべきだと

ご指摘を頂きました。



> タスクの粒度だと思います。タスクが大きい場合は今までのExecutor、

小さい場合 fork-joinという使い分けになると思います



確かに、使用用途としては上記であるべきだと思います。

私の説明ではマージソートの例が先にありきで説明しているので、

一般的な説明ではありませんでした。



Brian Goetz は過去の Java One で下記のように報告しております。

P17, P18 において性能に関する考慮点として下記のように説明しています。



● これ以上分割せずに逐次処理する閾値をどの位にするか

● 性能上のトレードオフ

  >タスクを小さくすれば並列度は上がります。

    負荷分散が最適に施され、スループットが向上します

  >タスクを大きくすればタスク管理のオーバヘッドが減少します

    タスクの作成、キューへの追加、キューからの取り出し、

    タスクの実行、完了を待つ操作をタスク毎に実行する必要がある

● Fork-Join タスクフレームワークは計算中心の処理でタスク辺りのオーバヘッドを

 最小化するように設計されています。

  >タスク管理のオーバヘッドが小さければ、逐次処理の閾値をより小さくできます。

  >従来の Executor フレームワークは CPU 処理と I/O 処理が混在するタスクに向いています。

●  Fork-Join は並列アルゴリズムの表現に幅広く使用できます。

  >実行時のトポロジーに依存しないコードを書くことができます。

  >それほど、CPU数に左右されず妥当な性能を出すことができます。

  >並列度はライブラリが管理します。

   ー通常は同期処理を記述する必要はありません。

  >Fork-Joinプールにスレッド数を設定する必要があります。

   ーRuntime.availableProcessors()が通常は最適な方法です


広告

Entry filed under: Application Server/GlassFish.

Java Werehouse ベータリリース 週末の散歩

2件のコメント

  • 1. さくらば  |  2009年9月30日12:06 AM

    資料の中で fork-join の説明に
    > 大量の計算が必要な場合、処理を分割し、分割された中で個別に
    > 計算し最後に結果を集計するような場合に有効(再帰計算等)
    とありますけど、ちょっと違うのではないでしょうか。
    ポイントはタスクの粒度だと思います。タスクが大きい場合は今までのExecutor、小さい場合 fork-joinという使い分けになると思います。
    去年の JavaOne の TS-5515 の中で Goetz は次のように示しています。
    • Making tasks smaller enhances parallelism
     • Increased load balancing, improves throughput
    • Making tasks larger reduces coordination overhead
     • Must create, enqueue, dequeue, execute, and wait for tasks
    前者がfork-joinが目指す所で、後者が Executor に相当しています。
    実際に Executor で小さいタスクを実行させると、メモリを食うばかりで、実行速度は全然速くなりません ><
    たとえば、クロージャーの議論の中で、コレクションに対するイテレータ (JavaのイテレータではなくRubyのイテレータです) も fork-join で実装することで並列性が高くなると Neal Gafter が主張しています。また、jsr166y の wiki にもコレクションに fork-join を使ったサンプルがのってます。
    このことからも分かるように、あまり計算量は関係ないと思います。
    # 確かに RecursiveAction とかあるので、再帰に使えばいいのか思いますけどね ^ ^;;

  • 2. Yoshio Terada  |  2009年9月30日4:15 AM

    さくらばさん、
    コメントありがとうございます。
    櫻庭さんにご指摘頂いて気づいたのですが
    確かに表現が間違っていたように思います。
    私の資料作成順としてマージソートの例を
    先に作成し、Fork-Join の使用理由を後から
    考え作成した表現でしたので表現が間違えた
    方向に向かってしまってました。
    後ほどコメント欄ではない部分に修正コメントを
    入れておきたいと思います。
    ご指摘頂きまして、ありがとうございました。


Java Champion & Evangelist

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2009年9月
« 8月   10月 »
 123456
78910111213
14151617181920
21222324252627
282930  

カテゴリー

Twitter

clustermap

ブログ統計情報

  • 987,455 hits

Feeds


%d人のブロガーが「いいね」をつけました。