Mercurial > hg > Papers > 2012 > yutaka-master
diff presen/presen1.html @ 24:716f0a413687 draft
add file
author | Yutaka_Kinjyo <yutaka@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 13 Feb 2012 11:55:11 +0900 |
parents | 02067287fac3 |
children | fa8b52588f67 |
line wrap: on
line diff
--- a/presen/presen1.html Sun Feb 12 23:01:44 2012 +0900 +++ b/presen/presen1.html Mon Feb 13 11:55:11 2012 +0900 @@ -75,52 +75,39 @@ </li> <li class="slide"> -<h1>研究背景と目的(1/2)</h1> +<h1>研究背景と目的</h1> <font size="5"> -当研究室では、マルチコアCPU上での開発を支援するたの、並列プログラミングフレームワーク Cerium を開発し、学生実験で使用している。本研究では -Cerium の信頼性の向上を目的とし、改良を行った (信頼性 = 仕様通りに動作する)<br> +<u>本研究では並列プログラムフレームワーク Cerium の改良を行い、並列処理の並列度向上とCell以外のマルチコアCPUへの対応に成功した。</u><br> -マルチコア上の並列プログラミングでは +<img src="pix/amdahl.jpg" style="display:block; width:50%; float: right; margin-top:0%"> + <ul> - <li>並列処理部分の特定や同期処理を適切に行わなければ、台数効果は得られない。</li> - <li>再現性ないバグなどが発生する可能性がある</li> - <li>アーキテクチャを理解し最適なプログラムを書く必要がある</li> + <li>アムダールの法則より、プログラム全体の並列化率が低ければマルチコアの性能を活かすことができない</li> + <li>現在の Cerium を用いたプログラムの開発では、高い並列度が保証されない</li> + <li>Cerium はPS3/Cell での並列処理を行えるが、当初はCell向けに作られた為、他の汎用マルチコアCPU に対応していない</li> </ul><br> -など信頼性のあるプログラムを開発するには逐次プログラミングよりも技術と手間がかかる問題がある<br> -Cell上でのゲーム作成を行う学生実験でも、講義期間中に作品が一定のレベルに達しない問題が生じた。そこで学生実験での使用を考慮した フレームワーク Cerium を開発した<br> +Cerium の他CPUへの対応と、自明な並列度があるレンダリングとゲーム処理を例題に、高い並列度の維持を目的とする </font> -<li class="slide"> -<h1>研究背景と目的(2/2)</h1> -<font size="5"> -Cerium を用いて 期間中のゲームの作成が可能になった。しかし学生実験での使用や、例題の実装を行い Cerium の信頼性が十分でない点が明らかになった。 -<ul> - <li>仕様通りの稼働率がでない</li> - <li>アーキテクチャ依存の記述が含まれている</li> -</ul><br> -以上の問題点を解決するため -<ul> - <li>ソフトウェアMailQueueの実装</li> - <li>TaskをグルーピングするTaskArrayの実装</li> - <li>明示的なDMAロードを隠蔽するMemorySegmentのAPIの実装</li> -</ul><br> -などの改良を行い、信頼性のある並列プログラミングフレームワークを目指す。 -</font> <li class="slide"> <h1>発表構成</h1> <ul> <li>Cellの機能</li> <li>Ceriumの構成</li> - <li>Ceriumに行った改良とその効果</li> + <li>Cerium の問題点1(Mail の待ち時間)</li> <ul> - <li>TaskArrayの実装(Mailの待ち時間の削減)</li> - <li>ソフトウェアMailQueueの実装(Mailの待ち時間の削減)</li> - <li>MemorySegmentの実装(アーキテクチャ依存記述の隠蔽)</li> + <li>TaskArray での改良と効果</li> + <li>MailQueue での改良と効果</li> + </ul> + <li>Cerium の問題点2(アーキテクチャ依存の記述)</li> + <ul> + <li>MemorySegmentでの改良と効果</li> </ul> <li>まとめ</li> + <li>OpenGLとの比較</li> <li>今後の課題</li> </ul> @@ -129,378 +116,288 @@ <font size="5"> 研究、実験の題材となった Cell Broadband Engine とは、 + +<img src="pix/cell.png" style="display:block; width:50%; float: right; margin-top:0%"> + <ul> - <li>ソニー、SCE、 IBM、 東芝によって開発されたプロセッサ</li> - <li>マルチコアで、9つのコアを持つ</li> + <li>1基のPPEと8基のSPEがリングバス(EIB)で構成されている。動作クロックは3.2GHz(実験で使えるSPEの数は6基)</li> + <li>リングバスのデータ帯域幅は1サイクルあたり最大96byte(3.2GHz駆動時には307.2GB/sec)</li> + <li>SPEは256KBのLocalStore(LS)を持つ</li> + <li>SPEからメインメモリへは直接アクセスできない</li> <ul> - <li>制御用コア PorwerPC Processor Element 1基</li> - <li>演算用コア Synergistic Processor Element 8基 (実験で使用できるのは6基)</li> - <li>各コアは Element Interconnect Bus を経由してデータアクセスを行う</li> + <li>SPEが持つMFC(Memory Flow Controller)へDMA命令を送ることで行う</li> </ul> </ul> -<p style="text-align: center;"> -<img class="scale" src="pix/cell.png" alt="" title="At a Glance" /> -</p> - </font> <li class="slide"> -<h1>Cellの機能(DMA転送)</h1> +<h1>Cellの機能</h1> <font size="6"> -Cell の SPE は直接 MainMemory にアクセスできない。 明示的な DMA 転送命令を用いてデータにアクセスする。転送するデータの条件として + +<u>Mailbox</u> <ul> - <li>16アラインメントに揃える</li> - <li>16byte の倍数のサイズでなければならない</li> - <li>一度の転送は16KB の大きさまでできる</li> -</ul><br> - -プログラムが明示的にDMA命令を発行して、データ転送を行う -</font> - -<li class="slide"> -<h1>Cellの機能(Mailbox)</h1> -<font size="6"> - -PPE と SPE の通信には Mailbox を用いる - -<ul> + <li>SPEのMFC内にあるFIFOキュー</li> <li>PPE と SPE 間で32ビットメッセージの交換ができる</li> - <li>Mail の Queue は3種類</li> + <li>Mail の Queue の種類</li> <ul> - <li>SPU inbound Mailbox: PPE -> SPE</li> - <li>SPU Outbound Mailbox: SPE -> PPE</li> - <li>SPU Outbound interrupt Mailbox: SPE -> PPE (割り込み)</li> + <li>SPU inbound Mailbox: PPE -> SPE (キューのサイズは4)</li> + <li>SPU Outbound Mailbox: SPE -> PPE (キューのサイズは1)</li> </ul> </ul><br> +Outbound Mailbox へ Mail を書き込む際、キューがいっぱいの時は、PPE 側から読み込まれるまで待つ。 </font> <li class="slide"> <h1>Cerium</h1> -<font size="6"> -Cerium とは +<font size="5"> +Cerium の構成 + +<img src="pix/cerium.png" style="display:block; width:50%; float: right; margin-top:0%"> <ul> - <li>並列プログラミング用のフレームワーク</li> - <li>学生実験での使用を考慮して PS3/Cell, Linux, MacOSX で動作する</li> - <li>Ceriumの構成</li> + <li>TaskManager</li> + <ul> + <li><font size="5">ユーザが定義したTaskを管理し、各コアに割り当てる</font></li> + </ul> + + <li>RenderingEngine</li> + <ul> + <li><font size="5">オブジェクトを画面に描画する</font></li> + <li><font size="5">3種類のTaskから構成される</font></li> + </ul> + + <li>SceneGraph</li> <ul> - <li>TaskManager</li> - <li>RenderingEngine</li> - <li>SceneGraph</li> + <li><font size="5">ゲームのシーンを作成し、それを切り替えながらゲームを進行する</font></li> + <li><font size="5">OpenSceneGraphのようなもの</font></li> </ul> + +</ul><br> + +</font> + +<li class="slide"> +<h1>TaskManager</h1> +<font size="5"> +TaskManager は、Taskと呼ばれる分割された各プログラムを管理する。Task の単位 +はサブルーチンである。Task 同士の依存関係を考慮しながら実行していく。</p> +<p>Task を生成する際に、以下のような要素が設定可能である</p> + +<ul> +<li><b>input data, output data, parameter</b><br> + これらは関数でいうところの引数に価する</li> +<li><b>cpu type</b><br> + Task を PPE または SPE のどちらで実行するのかを示している</li> +<li><b>dependency</b></li> + 他の Task との依存関係を示している +</li> </ul> + </font> <li class="slide"> <h1>TaskManager</h1> -TaskManager とは Task のスケジューラ +<font size="5"> + +<img src="pix/scheduler1.png" style="display:block; width:50%; float: right; margin-top:0%"> <ul> - <li>Task とよばれるデータ構造を提供</li> - <li>ユーザは処理(単位は関数に近い)を Task で記述していく</li> - <li>定義されたTask は、Task 情報に沿って各コアに処理を割り振られる</li> -</ul><br> - -Task で記述された部分の、自動的な並列処理スケジューリングを行う。 - -<li class="slide"> -<h1>RenderingEngine(1/2)</h1> -PS3 では Graphics Engine の仕様が公開されていないので、独自の RenderingEngine を開発した。 -Task で記述され、主に3つの Task から構成される -<ul> - <li>CreatePolygonTask</li> - <ul> - <li>モデリングデータを、三角形のポリゴンに変換する</li> - </ul> - <li>CreateSpanTask</li> - <ul> - <li>ポリゴンを水平な線(Span)に分割する</li> - </ul> - <li>DrawSpanTask</li> - <ul> - <li>Span を Texture とマッピングし画面に出力する</li> - </ul> + <li>生成された Task は TaskList としてまとめられ SPE で実行される</li> + <li>SPE 側では受け取った TaskList から Task を受け取り、パイプライン的に実行していく</li> </ul> -<li class="slide"> -<h1>RenderingEngine(2/2)</h1> - -例: Cube のモデリングデータの場合には、以下のように Task が働く。 - -<p style="text-align: center;"> -<img class="scale" src="pix/rendering3.png" width="50%" alt="" title="At a Glance" /> -</p> - -<li class="slide"> -<h1>SceneGraph</h1> -ゲームのシーンを構成する木構造のグラフ。各 Node がゲームのオブジェクトになる。オブジェクトには Move 関数と collision 関数が設定でき、ステイトパターンで入れ替える。 - -<p style="text-align: center;"> -<img class="scale" src="pix/scenegraph1.png" width="30%" alt="" title="At a Glance" /> -</p> +</font> <li class="slide"> -<h1>Cerium の改良(Mailの待ち時間)</h1> -<font size="5"> -RenderingEngine を用いた例題で、ball bound, panel がある。(FPS = Frame per second) - -<table border="1" cellspacing="0" cellspacing="2" cellpadding="5" align="center"> -<tr> -<th></th> -<th>FPS</th> -<th>DMA転送待ち割合</th> -<th>mail待ち割合</th> -<th>SPE稼働率</th> -</tr> -<tr> -<th>ball bound</th> -<th>30.2</th> -<th>1.8%</th> -<th>74.3%</th> -<th>23.7%</th> -</tr> -<tr> -<th>panel</th> -<th>4.0</th> -<th>21.3%</th> -<th>11.1%</th> -<th>67.6%</th> -</tr> -</table> - +<h1>Mailのやり取り</h1> +<font size="6"> <ul> - <li>panel</li> + <li>SPE と PPE 間の同期は Mail のやり取りを行う</li> + <br> + <li>Mailのタイミング</li> + <br> + <font color="red">SPE -> PPE</font> <ul> - <li>解像度1980x1080の一枚の画像の描画行う。</li> + <li>タスクの終了(Taskの依存関係の解決のため)</li> + <li>新しい TaskList のリクエスト</li> </ul> - <li>ball bound</li> + <br> + <font color="red">PPE -> SPE</font> <ul> - <li>球が跳ねる例題。</li> + <li>新しい TaskList の送信</li> </ul> </ul> -ball bound では Mail 待ちが約70%、稼働率23%と十分な稼働率ではない。(panel は ball bound より描画の処理が重く、その分稼働率が高くなっている)<br> -アムダールの法則より稼働率がでないとマルチコアの性能は発揮されない。フレームワークとしての信頼性が十分でない問題がある </font> <li class="slide"> -<h1>Mail 通知のスケジューリング</h1> -稼働率を向上させるために、Mail の待ち時間を削減する。<br><br> -Cerium では SPE が Mail で 待ち時間が発生するタイミングは2つ - -<ul> - <li>TaskList を待つ場合</li> - <li>SPE から Mailbox へ書き込む際の待ち</li> -</ul> - -<li class="slide"> -<h1>TaskListのMail待ち</h1> -TaskList は処理する Task の List である。PPE で生成され SPE へ Mail で通知される - -<p style="text-align: center;"> -<img class="scale" src="pix/tasklistmail1.png" width="80%" alt="" title="At a Glance" /> -</p> - -TaskList が生成され SPE に通知されるまで、SPE に待ち時間が発生する。 +<h1>PPEとSPEで行われるパイプライン処理</h1> +<font size="5"> +PPEとSPE 間で Mail を介して Task の実行をパイプライン化している。 +Mail の受け取りは PPE 側から定期的にポーリングするしかなく、PPE のMain ループで定期的に チェックしている。<br> +<u>パイプラインがうまく動作する例</u> +<img src="pix/mailsched1.png" style="display:block; width:60%; float: center; margin-top:0%"> -<li class="slide"> -<h1>Mail の書き込み待ち</h1> -Task が終了した際と TaskList が終了した際に SPE が Mailbox へ書き込みを行う(依存関係解決のため)。Outbound Mailbox はサイズが1なので、他のMailが書き込まれている場合、それが PPE側から読み込まれるまで、待つ。 - -<p style="text-align: center;"> -<img class="scale" src="pix/mailschedule2.png" width="80%" alt="" title="At a Glance" /> -</p> - -TaskList が生成され SPE に通知されるまで、SPE に待ち時間が発生する。 +当初はこれでうまくパイプラインが実行されていると思われていたが、うまくいかないパターンが存在することが明らかになった。 -<li class="slide"> -<h1>TaskArray(1/3)</h1> -<font size="5"> -Task毎に依存関係の解決のため、Mail を通知する。バリア同期など複数の Task が同じ Task を待つ場合にはグルーピングできる。 -Task のグルーピングを可能にするために TaskArray を実装した。 - -<p style="text-align: center;"> -<img class="scale" src="pix/taskarray1.png" width="80%" alt="" title="At a Glance" /> -</p> - </font> <li class="slide"> -<h1>TaskArray(2/3)</h1> -例えば TaskListのサイズが4, TaskArray のサイズが4の場合、Task が8個の場合 +<h1>PPEとSPEで行われるパイプライン処理</h1> +<font size="5"> +PPE 側で実行される Task の処理が多い時に、Mail チェックの頻度が少なくなる。 +Outbound Mailbox がひとつの Mail で占有される時間が長くなり、SPE 側の終了した Task の終了Mail が書き出せなくなる。 +そのため、書き込み待ちが発生し、SPE に待ち時間が発生する。<br> +<u>パイプラインが崩れてしまう例</u> +<img src="pix/mailsched2.png" style="display:block; width:57%; float: center; margin-top:0%"> -<p style="text-align: center;"> -<img class="scale" src="pix/taskarray2.png" width="80%" alt="" title="At a Glance" /> -</p> +これが並列度の低下を招いている。 +</font> -グルーピングされるため Task 毎の Mail 回数が減る。TaskList の要求回数が減る。そのため Mail の待ち時間が入る箇所が削減され、Mail の待ち時間自体の削減につながる。 <li class="slide"> -<h1>TaskArray(3/3)</h1> +<h1>PPEとSPEで行われるパイプライン処理</h1> +<font size="5"> +そこで、その問題を解決するため、一つ目のアプローチとして Outbound Mailbox と Task の終了処理の間に ソフトウェア MailQueue を導入した。 +Outbound Mailbox がいっぱいの場合その Queue に Task 終了 Mail を挿入し、次の Task が実行されるようになった<br> + +<u>MailQueueを導入によりパイプラインが正常に動作している例</u> +<img src="pix/mailsched3.png" style="display:block; width:55%; float: center; margin-top:0%"> + +そのため、SPE の待ち時間が無くなり、並列度が向上した。<br> +</font> + +<li class="slide"> +<h1>PPEとSPEで行われるパイプライン処理</h1> <font size="5"> -TaskArray の効果を示す +二つ目のアプローチとして、複数の Task を TaskArray としてグルーピングする 方法を考えた。 +依存関係が線形である Task は TaskArray としてまとめることにより、Task 終了のメールを減らすことが出来る。 +<img src="pix/taskarray3.png" style="display:block; width:60%; float: center; margin-top:0%"> +TaskArrayを導入することによって、wait time が削減された。 +<img src="pix/taskarray2.png" style="display:block; width:60%; float: center; margin-top:0%"> +これにより、並列度が向上した。 +</font> + +<li class="slide"> +<h1>改良効果の測定</h1> +RenderingEngine を用いて、効果を計測した。レンダリングの例題として、ball bound と panelを用いた。<br> +ball bound は赤いボールが跳ねる例題である。描画領域が画面の中でボールの部分だけであり、描画領域が狭いと言える。<br> +panel は画面一面に画像を描画する例題である。描画領域が最大である。<br> +<img src="pix/ball_bound1.png" style="display:block; width:30%; float: left; margin-top:0%"> +<img src="pix/panel1.png" style="display:block; width:30%; float: right; margin:5% 20% 0% 20%"> + +</font> + +<li class="slide"> +<h1>改良効果の測定</h1> +<font size="5"> <table border="1" cellspacing="0" cellspacing="2" cellpadding="5" align="center"> <caption>ballbound</caption> + <tr> -<th>TaskArray</th> +<th>改良項目</th> <th>FPS</th> -<th>DMA転送待ち時間</th> <th>mail待ちの割合</th> <th>SPE稼働率</th> +<th>SPE稼働率の差分</th> </tr> + <tr> -<th> なし </th> +<th>改良なし</th> <th>30.2</th> -<th>1.8%</th> <th>74.3%</th> <th>23.7%</th> +<th>-</th> </tr> -<tr> <tr> -<th> あり </th> +<th>TaskArray適用後</th> <th>32.2</th> -<th>2.5%</th> <th>66.7%</th> <th>30.8%</th> +<th><font color="red">+7.1%</font></th> </tr> +<tr> +<th>MailQueue適用後</th> +<th>41.7</th> +<th>56.8%</th> +<th>40.0%</th> +<th><font color="red">+10.8%</font></th> +</tr> + + </table> <table border="1" cellspacing="0" cellspacing="2" cellpadding="5" align="center"> <caption>panel</caption> + <tr> -<th>TaskArray</th> +<th>改良項目</th> <th>FPS</th> -<th>DMA転送待ち時間</th> <th>mail待ちの割合</th> <th>SPE稼働率</th> +<th>SPE稼働率の差分</th> </tr> -<th>なし</th> +<th>改良なし</th> <th>4.0</th> -<th>21.3%</th> <th>11.1%</th> <th>67.6%</th> +<th>-</th> </tr> <tr> -<th>あり</th> +<th>TaskArray適用後</th> <th>4.2</th> -<th>22.5%</th> <th>5.7%</th> <th>71.8%</th> +<th><font color="red">+4.2%</font></th> +</tr> + +<tr> +<th>MailQueue適用後</th> +<th>4.2</th> +<th>4.1%</th> +<th>72.3%</th> +<th><font color="red">+0.5%</font></th> </tr> </table> -TaskArray を ball bound, panel の DrawSpanTask に適応。FPS、稼働率の向上。Mail 待ちの時間が削減された +改良を加え 各例題 の<u>FPS、稼働率の向上。Mail 待ちの時間が削減され、並列度が向上したといえる</u> </font> <li class="slide"> -<h1>MailQueue(1/3)</h1> -Task 毎の Mail 書き込み時の待ち時間を削減するため、MailQueue を実装した。 - +<h1>他のアーキテクチャへの対応</h1> +PS3 が Linux をサポートしなくなっため、これ以上のCell上での実験が困難になってきている。<br> <ul> - <li>SPE から Mailbox に書き出せない場合に MailQueue へと書きだす</li> - <li>MailQueue に Mail がある場合は、MailQueue から Mailbox へ書き出す</li> - <li>MailQueue に残っている Mail は TaskList のTask を消化した時点で、すべて書き出す処理を挟む</li> + <li>これまでアーキテクチャ依存を排除して MacOSX,Linux などの上でも動作する設計を行なっていたため他のアーキテクチャでも動作はする。</li> + <li>しかし並列実行はサポートしておらず、FIFOを用いた 逐次処理のみをサポートしていた。 </li> </ul> -<li class="slide"> -<h1>MailQueue(2/3)</h1> - -Mailbox に書き込めない場合は、MailQueue に書き込む例 - -<p style="text-align: center;"> -<img class="scale" src="pix/mailqueue1.png" width="70%" alt="" title="At a Glance" /> -</p> +そこで、汎用マルチコア向けのパラレルタスクのサポートを行った。 <li class="slide"> -<h1>MailQueue(3/3)</h1> -<font size="5"> -MailQeueuの効果 - -<table border="1" cellspacing="0" cellspacing="2" cellpadding="5" align="center"> -<caption>ball bound</caption> -<tr> -<th>MailQueue</th> -<th>FPS</th> -<th>DMA転送待ち時間</th> -<th>mail待ちの割合</th> -<th>SPE稼働率</th> -</tr> -<tr> -<th> なし </th> -<th>32.2</th> -<th>2.5%</th> -<th>66.7%</th> -<th>30.8%</th> -</tr> -<tr> - -<tr> -<th> あり </th> -<th>41.7</th> -<th>3.3%</th> -<th>56.8%</th> -<th>40.0%</th> -</tr> +<h1>他のアーキテクチャへの対応</h1> -</table> - -<table border="1" cellspacing="0" cellspacing="2" cellpadding="5" align="center"> -<caption>panel</caption> -<tr> -<th>MailQueue</th> -<th>FPS</th> -<th>DMA転送待ち時間</th> -<th>mail待ちの割合</th> -<th>SPE稼働率</th> -</tr> +異なるアーキテクチャで動作させるにあたり、アーキテクチャの依存を吸収できるインターフェイスが望ましい。<br> +現在のSPEからのメモリアクセスは直接DMA転送を行うのではなく、MemorySegment API を用いて記述している。 +MemorySegment API は、読み込んだデータの LSへのLRU方式のキャッシュをサポートする。そのため無駄なデータの転送が +削減された。 +このAPIを用いる前は、Task内部で直接DMA転送を行っており、一度LSに読み込んだデータを再利用する機構がなかった。 +このMemorySegmentのAPIには MainMemory のアドレスが用いられており、Cell 以外のアーキテクチャでも問題なく動作する。 -<tr> -<th>なし</th> -<th>4.2</th> -<th>22.5%</th> -<th>5.7%</th> -<th>71.8%</th> -</tr> - -<th>あり</th> -<th>4.2</th> -<th>23.7%</th> -<th>4.1%</th> -<th>72.3%</th> -</tr> - -</table> -</font> - -ball bound , panel ともに Mail 待ち時間が削減され、稼働率、FPS の向上につながった。 <li class="slide"> -<h1>Ceriumの改良(アーキテクチャ依存記述の隠蔽)</h1> -RenderingEngine の Task内 では明示的にDMA転送命令を記述している。 - -<ul> - <li>処理するデータ構造上の理由、Task内でのデータロードが必要</li> - <li>DMA転送命令は Cell アーキテクチャ依存の記述</li> - <li>他のアーキテクチャなどでは不要</li> -</ul><br> - -フレームワークとしての汎用性に欠ける。 -アーキテクチャ依存の記述を隠蔽できるAPIが必要になった。 - -<li class="slide"> -<h1>MemorySegment(1/6)</h1> +<h1>Ceriumの改良-MemorySegment(1/6)</h1> 明示的なDMA転送命令を隠蔽するため MemorySegment を実装した MemorySegemnt はデータ構造。LS 内のデータを管理する。 <ul> @@ -515,7 +412,7 @@ </ul> <li class="slide"> -<h1>MemorySegment(2/6)</h1> +<h1>Ceriumの改良-MemorySegment(2/6)</h1> <p style="text-align: center;"> <img class="scale" src="pix/getsegment1.png" width="50%" alt="" title="At a Glance" /> @@ -523,136 +420,32 @@ <li class="slide"> -<h1>MemorySegment(3/6)</h1> +<h1>Ceriumの改良-MemorySegment(3/6)</h1> <p style="text-align: center;"> <img class="scale" src="pix/putsegment1.png" width="50%" alt="" title="At a Glance" /> </p> - <li class="slide"> -<h1>MemorySegment(4/6)</h1> -明示的に記述したDMA転送命令の例 -<pre> -loop() { - - tmp_data = get_data; - get_data = send_data; - send_data = tmp_data; - - dma_wait(WAIT_STORE); - - dma_store(send_data, send_addr, data_size, WAIT_STORE); - dma_load(get_data, get_addr, data_size, WAIT_LOAD); - - dma_wait(WAIT_LOAD); - - calc(get_data); - -} -</pre> - -<li class="slide"> -<h1>MemorySegment(5/6)</h1> -MemorySegment を適応させた例 -<pre> -loop() { - - wait_segment(put_ms); - - put_ms = get_ms; - - put_segment(put_ms); - get_ms = get_segment(get_addr, ml); - - wait_segment(get_ms); - get_data = get_ms->data; - - calc(get_data); -} -</pre> - -<li class="slide"> -<h1>MemorySegment(6/6)</h1> -MemorySemgment を導入 +<h1>Ceriumの改良-MemorySegment(6/6)</h1> +MemorySegment を導入し、 <ul> <li>アーキテクチャ依存の記述を隠蔽することに成功した</li> <li>汎用的な Task 内でのデータ転送APIとして使用でき</li> - <li>Core i7, Xeon などの汎用のメニーコアにも対応可能</li> + <li>Core i7, Xeon などの汎用のマルチコアにも対応可能</li> </ul> <li class="slide"> -<h1>まとめ(1/2)</h1> +<h1>まとめ</h1> 並列プログラミングフレームワーク Cerium の改良を行った。 <ul> <li>MailQeueu, TaskArry を実装、導入した。その結果 Mail の待ち時間の削減、稼働率と FPS の向上に成功した</li> - <li>MemorySegment を実装し、汎用的なデータ転送APIが利用できるようになった。Cell アーキテクチャ依存の記述の隠蔽に成功</li> + <li>MemorySegmentを適応し、汎用的なデータ転送APIが利用できるようになった。</li> </ul><br> -以上の改良を行い、稼働率の向上、アーキテクチャ依存のコードの排除に成功し、フレームワークとしての信頼性が向上した。 - -<li class="slide"> -<h1>まとめ(2/2)</h1> - -改良の効果を示す - -<font size="5"> -<table border="1" cellspacing="0" cellspacing="2" cellpadding="5" align="center"> -<caption>ball bound</caption> -<tr> -<th></th> -<th>FPS</th> -<th>DMA転送待ち時間</th> -<th>mail待ちの割合</th> -<th>SPE稼働率</th> -</tr> -<tr> -<th>改良前</th> -<th>30.2</th> -<th>1.8%</th> -<th>74.3%</th> -<th>23.7%</th> -</tr> -<tr> - -<tr> -<th>改良後</th> -<th>41.7</th> -<th>3.3%</th> -<th>56.8%</th> -<th>40.0%</th> -</tr> -</table> - -<table border="1" cellspacing="0" cellspacing="2" cellpadding="5" align="center"> -<caption>panel</caption> -<tr> -<th></th> -<th>FPS</th> -<th>DMA転送待ち時間</th> -<th>mail待ちの割合</th> -<th>SPE稼働率</th> -</tr> - -<tr> -<th>改良前</th> -<th>4.0</th> -<th>21.3%</th> -<th>11.1%</th> -<th>67.6%</th> -</tr> - -<th>改良後</th> -<th>4.2</th> -<th>23.7%</th> -<th>4.1%</th> -<th>72.3%</th> -</tr> - -</table> -</font> +以上の改良を行い、稼働率の向上、Cellのみでなく、他の汎用マルチコアCPUへの対応にも成功した。 <li class="slide"> <h1>OpenGL との比較</h1> @@ -691,7 +484,7 @@ <li>扱うデータから Task の依存関係がわかる</li> <li>ユーザが複雑な依存関係を設定しない</li> </ul> - <li>プログラムとデータの On demand Load</li> + <li>DataSegment</li> <ul> <li>プログラムコードはすべて LS に置いている</li> <li>LS の容量を圧迫しプログラムが動作しなくなる</li>