|
0
|
1 \chapter{結論} \label{chapter:conclusion}
|
|
|
2 \section{まとめ}
|
|
1
|
3 本研究では並列プログラミングフレームワーク Cerium の改良を行った。Cerium は並列プログラミングをサポートする TaskManager、ソフトウェアレンダリングを行う RenderinEngine, ゲームのシーンを記述していく、SceneGraph から構成されている。学生実験で行うCell上でのゲーム作成を考慮にいれた並列プログラミングフレームワークである。Ceirum 開発後に学生実験での使用や、例題を実装していく上で、仕様通りの稼働率がでないことや、アーキテクチャ依存の記述が避けづらいことなど、フレームワークとしての信頼性が十分でないことが明らかになった。
|
|
4
|
4 特に Cell上での実行の場合には、SPE との通信の待ち時間が約70\%と、処理性能に関わっている。そこで SPE と PPE の通信部分である Mail について、TaskArray の実装と使用、ソフトウェア MailQueue の実装をし改良を行った。その結果 FPS の向上、Mail 待ち時間の減少に効果が見られた。
|
|
|
5 また、Task 内でのアーキテクチャ依存の記述を MemorySegment によって、避けることに成功した。また MemorySegment を用いることでメモリ管理を抽象化することができる。その他の先行研究の改良として、Task のパイプライン化、Texutre のキャッシュなどがある。これらの改良によっても、FPS の向上や、DMA 転送の待ち時間が改善された。Cerium の改良を重ね、結果として約17 FPS の向上に成功した。また Mail の待ち時間は約18\%削減できた。
|
|
1
|
6
|
|
0
|
7 \section{今後の課題}
|
|
12
|
8
|
|
|
9 \subsection{Task 化 による並列化率の向上}
|
|
|
10
|
|
4
|
11 各コアの稼働率の向上のためには、さらに Mail の待ち時間を削減する必要がある。Mail の通信の待ち時間は内訳は
|
|
1
|
12
|
|
|
13 \begin{description}
|
|
|
14 \item PPE の対応が遅れる
|
|
|
15 \item SPE が他の SPE を待つ
|
|
|
16 \end{description}
|
|
|
17
|
|
|
18 の二つの要素がある。PPE の対応が遅れる場合には PPE側に処理するべきプログラムがあり、Mail の対応が遅れる原因がある。
|
|
12
|
19 そのため 制御用の PPE は処理するべきプログラムは排除し、Mail 通知の対応や、Task の割り振りを専門に PPE が行うことによって、SPE の稼働率向上を果たせると考える。
|
|
4
|
20
|
|
9
|
21 PPE での Task 管理以外の処理を排除するため、具体的には、プログラムの Task化 を行い Task の部分を SPE で処理する方法がある。現在 RenderingEngien 部分のほとんどが Task 化されているが、ScenenGraph 部分は Task 化されていない。今後の課題として SceneGraph 部分の Task 化が必要である。
|
|
1
|
22
|
|
12
|
23 \subsubsection{Task 化の問題点}
|
|
|
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 が扱うデータに対して、新たなデータ構造が必要だと考える。
|
|
1
|
33
|
|
12
|
34 \subsection{Taskの粒度}
|
|
|
35 バリア同期の際に 処理が早く終わった SPE が他の SPE を待つ時間を削減するために、Task はなるべく粒度を細かく設定することで解決できると考える。
|
|
4
|
36 粒度を細かくすることは、各 SPE への均等な Task の分散のために必要であり、並列化部分の特定にも繋がる。
|
|
|
37
|
|
|
38 \subsection{自動的な依存関係の解決}
|
|
12
|
39 Task 同士の依存関係の設定は、ユーザが、TaskManager の API を用いて行なっている。依存関係を設定するのは、処理するデータの整合性を保つためである。つまり、依存関係は Task が扱うデータと紐付けることができる。Task に設定されたデータを元に、Task の同士の依存関係関係を自動で解決することができると考える。
|
|
1
|
40
|
|
12
|
41 \subsection{SPE の LS の利用方法}
|
|
|
42 現在は定義された Task は SPE の LS へ一括ロードされ、保持されている。それによって処理の Task が増えるにつれて、LS を占有してしまう問題がある。特に SPE の LS は 256KB と一般的な CPU のメモリ容量に比べると小さく、同じようにプログラミングはできない。LS の容量を常に考慮したプログラミングが必要である。また Task だけではなく、扱うデータやSPEに常駐するカーネルプログラムもすべてメモリを消費するものなので、それらを扱う包括的なデータ構造が必要である。
|
