\chapter{結論}
\label{chap:poordirection}


\section{まとめ}

本研究では、I/Oを含む Task の並列処理の動作の改善を行った。
ファイルを mmap でメモリを確保すると、文字列検索を行う Task が読み込みを行い、それが終了後に検索が行われる。
読み込みが各 Task それぞれに割り当てられてしまうので、すべての Task が読み込み待ちとなってしまう。
それを解決する方法として、読み込みを行う Task と文字列検索を行う Task を分けるように Blocked Read の設計と実装を行った。

Blocked Read である程度の大きさを読み込んだら Task が順次起動するように実装したが、それだけだと順次読み込んでいる Blocked Read に Task が割り込まれてしまう。
そのようなことが起こらないように、Cerium Task Manager に新しいデバイスの設定 IO\_0 というタイプを追加した。このデバイスは、他のデバイス設定よりも priority を高く設定しているので、このタイプ以外で起動する Task に割り込まれることが起こらなくなる。

これらを実装した結果、本研究では mmap で実装したときよりも 36 \% の動作改善が見られた。
本研究を通して、I/O を含む Task の並列化の問題において、I/O の動作を改善する余地があると考える。

\section{今後の課題}
\subsection{実メモリ以上のファイルの取り扱い}
本研究での実験では、実メモリ以上のファイルを取り扱ってはいない。
Blocked Read のメリットとして、実メモリ以上のファイルサイズを取り扱うことができることである。
実メモリ以上のファイルを読み込む際には一旦分割して読み込み、その読み込み領域を担当する Task が終了したら、そのメモリ領域を解放する。
そして、その解放した部分に読み込みを行うことで、メモリの節約にも利用できる。

現段階での実装は、Task Manager 側で予めテキストファイルの大きさをメモリに確保して、その部分に読み込んだファイルを格納していくようになっている。
この実装方法ではメモリ以上のファイルを読み込めないので、この問題を解決する必要がある。

\subsection{Blocked Read で読み込んだファイルがキャッシュに残らない}
本来読み込みを行ったファイルは、一度プログラムを実行したあとでもキャッシュとしてメモリ上にテキストがそのまま残っている。
キャッシュとは、使用頻度の高いデータを高速なデバイスに蓄えておくことによって読み込みのオーバーヘッドを少なくするための機能である。

ハードディスクはメモリと比較すると読み込みが遅いので、ハードディスクからファイル読み込みを行うと、読み込みが速いメモリのほうに格納される。
読み込んだファイルが再利用されるとき、ハードディスクからメモリに格納するという時間が無くなるので、2回目以降の実行結果は速くなる。

mmap で実装を行うと、同じファイルに対して複数回検索を行うときに 2回目以降のプログラムの処理は速くなる。
本研究では mmap で 10GB のファイルに対して文字列検索を行うと約150秒かかるが、2回目以降の実行速度に関しては、約7秒でプログラムが終了する。

Blocked Read も 2回目以降の実行速度は mmap と同様に速くなるのだが、ある一定のファイルサイズを越えてしまうとキャッシュが無効となってしまう。
10GB のファイルではそのようなことが発生することは確認しているが、どれくらいの大きさからキャッシュが無効になるのか不明である。

キャッシュが無効になってしまうと、Blocked Read で実装した文字列検索は複数回実行するときに不利となる。
なぜこのようなことが起こるのか調査して、それが起こらないように実装していきたい。

\subsection{Blocked Read を Cerium API化}
現段階での Blocked Read の実装は、複雑な書き方で実装しなければならない。
この実装を Cerium の API に落としこむことによって、簡単に実装できるようにしたい。