Fine grain Task Manager Cerium のチューニング

Yutaka Kinjyo, Shinji Kono

琉球大学大学院理工学研究科情報工学専攻並列信頼研

研究目的 と 背景

現在 Cell/PS3またはMac OS X上で動作するOpen CL 的なFine Grain Task Manager である Cerium Task Manager を開発中である。

• ソフトウェアレンダリングエンジンとWord countを例題として、Task Manager の実装時の問題を洗い出している。


• メインメモリ上の Task を各 Core が受け取る際や、その終了を通知する際に待ち時間が生じる。

本研究ではその待ち時間を削減するTask array、メモリのアクセス方法を提案し実装した。その効果について報告する

Cellとは

Ceriumとは

• TaskManager
• レンダリングエンジン
• SceneGraph

Ceriumとは

• TaskManager
• レンダリングエンジン
• SceneGraph

TaskManager

• TaskManagerは、Taskと呼ばれる、分割された各プログラムを管理する
• Taskの単位はサブルーチン
• Task同士の依存関係を考慮
• 実行可能になったTaskをSPEに渡す

CeriumにおけるTask

• Input data
• Output data
• Paramater
• CPU type
• Dependency

CeriumにおけるTask

• Dependencyは他のTaskとの依存関係を示す。
• 例えばTaskAがTaskBをwaitする場合、TaskBが実行完了すると、TaskAが実行可能になる。
• Taskの実行完了は、SPEのMail送信ボックスにデータが書き込まれ通知される。

CeriumにおけるTask

• Cellの機能の１つ
• 32bitのメッセージをPPE,SPE間でやりとりできる
• 送信ボックス、受信ボックスがSPEに設けられている。
• それぞれMailボックスはキューになっている
• 受信ボックスのサイズは4
• 送信ボックスのサイズは1

CeriumにおけるTask

• 送信ボックスのデータはPPEから、受信ボックスのデータはSPEから呼び出される
• 書き込みはその逆

Taskの送信

• Taskは１つ毎にSPEには送らない
• いくつかのTaskをまとめTaskListとして送る
• TaskListをすべて完了すると、SPEからPPEへのMailが書き込まれる
• PPE側がMailをチェックし次のTaskListをMailで通知する

SPEの待ち時間

• 送信Mailボックスに書き込もうとしたとき、 ボックスがいっぱいの場合は、PPEから呼び出されるまでSPEは待ち続ける
• TaskManagerでは、受信ボックスがいっぱいになることはない。
• PPEでMailのチェック、返信があるまで、SPEは止まってしまう
• SPEの待ち時間が増えると、処理速度の低下につながる

Sort

• time : 実行時間
• dma wait : dma転送の待ち時間の割合
• mail wait : mailの待ち時間の割合
• sortする対象は30,000個のランダムな値
• Quick sortを行う

Sort

• SPEの稼働率は約98%。
• Sortの場合、SPEの待ち時間がほとんど無く高速に動作する
• WordCount,レンダリングエンジンの場合は待ち時間がはいる

• WordCountTask(TaskArray化)
• Input data であたえられたデータをwcし、output data に書き出す
• PrintTask
• 各SPEから書き出されたwcデータを集計し、出力する
• dependency に WordCountTaskを設定

WordCount

• wcするfileをマッピングし、Taskに割り振る
• WordCountTaskの終了をまって、PrintTaskが実行される

WordCount

• Sort に比べて、dima wait, mail wait の割合が大きい

TaskArray

• TaskArrayは複数のTaskを１つにまとめることができる
• Task毎のMail通知がTaskArray毎のMail通知になる
• 依存関係のグルーピングができる

TaskArray

• Mailの数が減り、SPEのMail待ちのタイミングが減る
• Mail待ちが減るので、SPEの稼働率が向上する

WordCount

• TaskArrayのサイズは64

• Mail wait の割合が減少、代わりに dma wait が増加
• TaskArrayは、最初にdma転送でTaskArrayの中のTaskを取得する

WordCount

• 大きなファイルをメモリにマッピングするためスワップが起きる
• dmaでメモリにアクセスするときに、時間がかかり待ち時間が生じるていると考えられる

WordCount

• 一度にすべてのTaskを生成せず、一定のTaskを生成、実行を繰り返す
• 同期する地点を設け、特定のSPEがはしり過ぎないようにする

WordCount

• 次のTaskは、今のTaskが終わってから生成するので、その間の待ちがある
• PPE側で先に次のTaskを用意しておくことで、改善できるはず
• また、Task同様マッピング自体も複数回にわけて行うことで、局所性が維持できる

TaskArray

• CreatePolygonTask
• Polygonを生成する
• CreateSpanTask
• Polygonを水平な線(Span)に分割する
• DrawSpanTask(TaskArray化)
• Spanを描画する

レンダリングエンジン

• FPS : 一秒間に表示するFrame数
• TaskArrayの適応の有無を比較
• TaskArrayのサイズは8

レンダリングエンジン

• mail wait 割合が減少し、それに伴ってFPSも増加
• レンダリングエンジンの場合、PPE側で実行するTaskがある
• PPEのMailチェックがおくれることがあるので、TaskArrayの効果がある
• Mail wait の細かい内訳はまだわかっていない

レンダリングエンジン

• PPE側のTaskをSPEに任せ、PPEの負担をへらす
• 別スレッドでMailを監視する
• 他のTaskもTaskArray化する
• Mail wait の細かい内訳を調べる

まとめ

• 複数のTaskをまとめるTaskArrayを提案、実装した。
• PPE側が忙しい場合、Mail待ち時間の削減にTaskArrayの効果がみられる
• 大量のメモリを消費する処理の場合
• マッピングの方法、Taskのスケジューリングを工夫して局所性を維持することでdma転送時間を削減できる

end

/*end*/


[any material that should appear in print but not on the slide]