Mercurial > hg > Papers > 2012 > yutaka-master

comparison paper/conclusion.tex @ 12:3c0f43537ca6 draft

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
fix
author Yutaka_Kinjyo <yutaka@cr.ie.u-ryukyu.ac.jp>
date Thu, 09 Feb 2012 20:54:59 +0900
parents b69eefd9156e
children
comparison
equal deleted inserted replaced
11:883d5e524f4b 12:3c0f43537ca6
3 本研究では並列プログラミングフレームワーク Cerium の改良を行った。Cerium は並列プログラミングをサポートする TaskManager、ソフトウェアレンダリングを行う RenderinEngine, ゲームのシーンを記述していく、SceneGraph から構成されている。学生実験で行うCell上でのゲーム作成を考慮にいれた並列プログラミングフレームワークである。Ceirum 開発後に学生実験での使用や、例題を実装していく上で、仕様通りの稼働率がでないことや、アーキテクチャ依存の記述が避けづらいことなど、フレームワークとしての信頼性が十分でないことが明らかになった。 3 本研究では並列プログラミングフレームワーク Cerium の改良を行った。Cerium は並列プログラミングをサポートする TaskManager、ソフトウェアレンダリングを行う RenderinEngine, ゲームのシーンを記述していく、SceneGraph から構成されている。学生実験で行うCell上でのゲーム作成を考慮にいれた並列プログラミングフレームワークである。Ceirum 開発後に学生実験での使用や、例題を実装していく上で、仕様通りの稼働率がでないことや、アーキテクチャ依存の記述が避けづらいことなど、フレームワークとしての信頼性が十分でないことが明らかになった。
4 特に Cell上での実行の場合には、SPE との通信の待ち時間が約70\%と、処理性能に関わっている。そこで SPE と PPE の通信部分である Mail について、TaskArray の実装と使用、ソフトウェア MailQueue の実装をし改良を行った。その結果 FPS の向上、Mail 待ち時間の減少に効果が見られた。 4 特に Cell上での実行の場合には、SPE との通信の待ち時間が約70\%と、処理性能に関わっている。そこで SPE と PPE の通信部分である Mail について、TaskArray の実装と使用、ソフトウェア MailQueue の実装をし改良を行った。その結果 FPS の向上、Mail 待ち時間の減少に効果が見られた。
5 また、Task 内でのアーキテクチャ依存の記述を　MemorySegment によって、避けることに成功した。また MemorySegment を用いることでメモリ管理を抽象化することができる。その他の先行研究の改良として、Task のパイプライン化、Texutre のキャッシュなどがある。これらの改良によっても、FPS の向上や、DMA 転送の待ち時間が改善された。Cerium の改良を重ね、結果として約17 FPS の向上に成功した。また Mail の待ち時間は約18\%削減できた。 5 また、Task 内でのアーキテクチャ依存の記述を　MemorySegment によって、避けることに成功した。また MemorySegment を用いることでメモリ管理を抽象化することができる。その他の先行研究の改良として、Task のパイプライン化、Texutre のキャッシュなどがある。これらの改良によっても、FPS の向上や、DMA 転送の待ち時間が改善された。Cerium の改良を重ね、結果として約17 FPS の向上に成功した。また Mail の待ち時間は約18\%削減できた。
6 6
7 \section{今後の課題} 7 \section{今後の課題}
8
9 \subsection{Task 化 による並列化率の向上}
10
8 各コアの稼働率の向上のためには、さらに Mail の待ち時間を削減する必要がある。Mail の通信の待ち時間は内訳は 11 各コアの稼働率の向上のためには、さらに Mail の待ち時間を削減する必要がある。Mail の通信の待ち時間は内訳は
9 12
10 \begin{description} 13 \begin{description}
11 \item PPE の対応が遅れる 14 \item PPE の対応が遅れる
12 \item SPE が他の SPE を待つ 15 \item SPE が他の SPE を待つ
13 \end{description} 16 \end{description}
14 17
15 の二つの要素がある。PPE の対応が遅れる場合には PPE側に処理するべきプログラムがあり、Mail の対応が遅れる原因がある。 18 の二つの要素がある。PPE の対応が遅れる場合には PPE側に処理するべきプログラムがあり、Mail の対応が遅れる原因がある。
16 そのため 制御用の PPE は処理するべきプログラムは排除し、Mail 通知の対応や、Task の割り振りを専門に PPE が行うことによって、SPE の稼働率向上を果たせると考える。また バリア同期を行うと 割り振られた処理によっては 他の SPE よりも早く処理が終了し、他の SPE を待つ時間が生じる場合がある。 19 そのため 制御用の PPE は処理するべきプログラムは排除し、Mail 通知の対応や、Task の割り振りを専門に PPE が行うことによって、SPE の稼働率向上を果たせると考える。
17 20
18 \subsection{Task 化 による並列化率の向上}
19 PPE での Task 管理以外の処理を排除するため、具体的には、プログラムの Task化 を行い Task の部分を SPE で処理する方法がある。現在 RenderingEngien 部分のほとんどが Task 化されているが、ScenenGraph 部分は Task 化されていない。今後の課題として SceneGraph 部分の Task 化が必要である。 21 PPE での Task 管理以外の処理を排除するため、具体的には、プログラムの Task化 を行い Task の部分を SPE で処理する方法がある。現在 RenderingEngien 部分のほとんどが Task 化されているが、ScenenGraph 部分は Task 化されていない。今後の課題として SceneGraph 部分の Task 化が必要である。
20 22
21 \subsubsection{SPE の LS の利用方法} 23 \subsubsection{Task 化の問題点}
22 現在は定義された Task は SPE の LS へ一括ロードされ、保持されている。処理の Task 化が進むにつれて、LS を占有し、 24 処理をTask 化していく上で、Task の構成が複雑化してきている。それは、TaskArray などの導入によるものである。Task を構成するには以下の注意点がある
25 \begin{itemize}
26 \item Task が扱う I/O データの分割と、16アラインメントに合わせた、適切なデータ構造の構成する。
27 \item データはランダムアクセスしてはいけない。
28 \item Task の同期のための、Task を生成する必要がある。
29 \item 扱う Data を考慮した 適切な Task の依存関係の設定がある。
30 \item Task が仕様通りに動作するか、テストを行う必要がある。
31 \end{itemize}
32 など、Task の構成には幾つかの注意点があり、これらを守らなければ仕様通りの性能はでない。より簡潔にプログラミングを行えるように、Task と　Task が扱うデータに対して、新たなデータ構造が必要だと考える。
23 33
24 34 \subsection{Taskの粒度}
25 \subsubsection{Taskの粒度} 35 バリア同期の際に 処理が早く終わった SPE が他の SPE を待つ時間を削減するために、Task はなるべく粒度を細かく設定することで解決できると考える。
26 バリア同期の際に 他の SPE を待つ時間を削減するために、Task はなるべく粒度を細かく設定することで解決できると考える。
27 粒度を細かくすることは、各 SPE への均等な Task の分散のために必要であり、並列化部分の特定にも繋がる。 36 粒度を細かくすることは、各 SPE への均等な Task の分散のために必要であり、並列化部分の特定にも繋がる。
28 37
29 \subsection{自動的な依存関係の解決} 38 \subsection{自動的な依存関係の解決}
39 Task 同士の依存関係の設定は、ユーザが、TaskManager の API を用いて行なっている。依存関係を設定するのは、処理するデータの整合性を保つためである。つまり、依存関係は Task が扱うデータと紐付けることができる。Task に設定されたデータを元に、Task の同士の依存関係関係を自動で解決することができると考える。
30 40
31 41 \subsection{SPE の LS の利用方法}
32 \subsection{DataSegment} 42 現在は定義された Task は SPE の LS へ一括ロードされ、保持されている。それによって処理の Task が増えるにつれて、LS を占有してしまう問題がある。特に SPE の LS は 256KB と一般的な CPU のメモリ容量に比べると小さく、同じようにプログラミングはできない。LS の容量を常に考慮したプログラミングが必要である。また Task だけではなく、扱うデータやSPEに常駐するカーネルプログラムもすべてメモリを消費するものなので、それらを扱う包括的なデータ構造が必要である。
33 \subsection{CodeSegment}