\chapter{結論} \label{chapter:conclusion}

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

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

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

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

OpenCL と CUDA を用いて GPGPU への対応を行った。
WordCount による測定を行ったが、データ並列実行をサポートすることで飛躍的な性能を確認できた。
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{今後の課題}
Cerium による GPGPU に関して、さらなる性能向上が見込める。
今回のベンチマークで、 Cerium による GPGPU と OpenCL 単体による GPGPU で、
Cerium の実行時間が OpenCL の1.01倍と、ほぼ同じ結果になった。
Cerium は Task の入出力と処理の部分をパイプラインにより並列に実行している。
本来であれば Cerium がパイプライン処理の分だけ並列度は高くなる。
パイプラインが適切に機能していないか、別のオーバーヘッドの存在が考えられる。
FFT 以外にも例題を作成し、オーバーヘッド部分の特定を行う必要がある。

更に、GPGPU の改善案として CPU と GPU の同時実行が考えられる。
Cerium では Task を CPU と GPU の両方に振り分けることができる。
Task を CPU で動かす場合と GPU で動かす場合では、
プラットフォームの得意とする計算が異なる事からも実行速度に差が生じるのは自明である。
CPU と GPU の両方の資源を活用して Task を実行することで、高い並列度が期待できる。
しかし Task をどの程度どのプラットフォームに振り分ければ良いかというのはあまり自明でない。
プラットフォームに対する Task の振り分けるは、Cerium が自動で Scheduling するのが望ましい。
基本的には GPU の方がコア数が多いため、優先して Task を振ることになる。
データの転送がオーバーヘッドとなる際に CPU 側に Task を振ることで並列度の向上が見込める。
依存関係のある Task を CPU と GPU に分けて振ってしまうとデバイス間の転送が起こり、
そこでロックが起きるので注意する必要がある。

【メモ】

マルチコア CPU ：特に無い？

GPGPU : 同時実行の話をいれる？同時実行時のschedulingを課題にする？

io : キャッシュの話。読み込みサイズが一定以上になるとキャッシュが無効になる。なんで？みたいな流れ

新設計：入れるにしてもなにから書こう。CS、DSから？

全体：Cerium を使用したアプリケションも何か欲しい