\chapter{結論} \label{chapter:conclusion}
本研究室で開発している Cerium を用いて、
マルチプラットフォーム対応並列プログラミングフレームワークに関する研究を行った。

マルチコア CPU や GPU といったマルチプラットフォームなアーキテクチャ上でリソースを有効活用するには、
それぞれのプラットフォームに対して適した形でプログラムが並列に動作できるようチューニングする必要がある。
しかしこれらのチューニングは非常に複雑になる。
動作させたいプラットフォームに対応した、適切なチューニングを行えるフレームワークが必要である。

Cerium では Scheduler がパイプラインの機構を持っており、Task はパイプラインに沿って実行されている。
Scheduler が受信した Task は既に TaskManager が依存関係を解決しているため、実行順序は任意で良い。
Cerium はプログラムの様々なレベルでパイプライン処理を行っており、
WordCount のようなシンプルな問題でも並列化することで性能向上する事が確認できた。

マルチコア CPU への対応として、 SynchronizedQueue を用いた機構を実装し、並列実行を可能にした。
WordCount と Sort による測定の結果、高い並列度を維持出来ていることを確認した。
また、より高い性能を持つ計算機で測定したところ、速度の向上を確認できた。

OpenCL と CUDA を用いて GPGPU への対応を行った。
WordCount による測定を行い、データ並列実行をサポートすることで OpenCL や CUDA と同等な性能を確認できた。
SIMD 型であることやループ命令を苦手とするといった理由から、
GPU における演算はデータ並列による実行をサポートしなければ性能が出ない事がわかった。
Cerium においてプログラマは Task を記述し、
Input データを用意した後はデータ並列用の API で Task を spawn することでデータ並列用の Task を生成する。
TaskManager はプログラマが記述した単一の Task を複数生成し、受け取ったデータ(Input)に対しその Task を割り当てる。
生成した複数の Task を並列実行する事でデータ並列実行を実現した。
また、GPU は SharedMemory でないため、入出力がネックになる場合が多い。
それらのオーバヘッドを吸収するために GPU 制御のコマンドはパイプライン形式で実行していくのが望ましい。

更に、 Blocked Read による並列処理向けのI/Oの実装を行った。
I/O 専用の Thread を追加し、Task が割り込みが起きた際のオーバーヘッドを減らすことに成功した。
一般的な file open である mmap と read の測定も行い、BlockedRead を含めたそれぞれの読み込みに対して、
どのような状況でより性能を発揮できるのか考察を行った。

\section{今後の課題}
Sort、WordCount、FFT と様々なベンチマークを行ったが、それぞれ Task 生成部分の記述が煩雑になるという問題が発生した。
例題によって Task を大量に生成する事があるが、生成と実行を一括で行ってしまうとデータがメモリを圧迫してしまい、
性能低下に繋がる。そこで Task をある一定の分割数で区切り、徐々に実行していく必要がある。
これを Task 間の依存関係で記述するのだが、この記述が原因でコードの量が増えてしまっている。
OpenCL では、MemoryBuffer の依存関係により暗黙的に Task 間で依存関係を設定することで Data Dependency を実現している。
Cerium でも Data Dependency を導入することにより、プログラマへの負担を減らすことができると考えられる。

Cerium による GPGPU に関して、さらなる性能向上が見込める。
今回のベンチマークで、 Cerium による GPGPU と OpenCL 単体による GPGPU で、
Cerium の実行時間が OpenCL の1.01倍と、ほぼ同じ結果になった。
Cerium は Task の入出力と処理の部分をパイプラインにより並列に実行している。
本来であれば Cerium がパイプライン処理の分だけ並列度は高くなる。
パイプラインが適切に機能していないか、別のオーバーヘッドの存在が考えられる。
FFT 以外にも例題を作成し、オーバーヘッド部分の特定を行う必要がある。

マルチコア CPU と GPU において、異なる形式でパイプラインを構築している。
マルチコア CPU では SchedTask を用いてパイプラインの構築を行ったが、
GPU 側では CommandQueue を2つ用意し、それを大きいループで回すことで構築した。
可読性の観点から、GPU 側もマルチコア CPU のように SchedTask によるパイプライニングを行うことが望ましい。
GPU 用の SchedTask を用意し、read() や write() 部分で OpenCL と CUDA の API を操作する事で実現できる。
可読性を向上させることはパイプライン部分のデバッグの行いやすさにも繋がる。