Mercurial > hg > Papers > 2014 > masakoha-sigos
view paper/conclusion.tex @ 11:14ce22f649d9
fix
author | Masataka Kohagura <e085726@ie.u-ryukyu.ac.jp> |
---|---|
date | Sun, 20 Apr 2014 16:25:41 +0900 |
parents | 91662ffcaf0b |
children | 6f6f482b9f12 |
line wrap: on
line source
\section{まとめと今後の課題} 本研究では、I/Oを含む Task の並列処理の動作改善を行った。 ファイルを mmap にて読み込むと、WordCount を行う Task がそれぞれ読み込みを行う。 読み込みが各 Task それぞれに割り当てられてしまうので、すべての Task が読み込み待ちとなってしまう。 それを解決する方法として、Read Task と文字列処理を行う Task を分けるように Blocked Read の設計と実装を行った。 Blocked Read である程度の大きさを読み込んだら Task が順次起動するように実装したのだが、それだけだと、順次読み込んでいる Blocked Read に Task が割り込まれてしまう。 そのようなことが起こらないように、Cerium Task Manager に新しいデバイスの設定 IO\_0 というタイプを追加した。 I/O が含まれるときの並列処理は、I/O のコントロールをプログラマが実装することで動作改善に繋がる。 本来読み込みを行ったファイルは、一度プログラムを実行したあとでもキャッシュとしてメモリ上にテキストがそのまま残っている。 %キャッシュとは、使用頻度の高いデータを高速なデバイスに蓄えておくことによって読み込みのオーバーヘッドを少なくするための機能である。 mmap で実装を行うと、同じファイルに対して複数回検索を行うときに 2回目以降のプログラムの処理は速くなる。 それに対して、 Blocked Read も 2回目以降の実行速度は mmap と同様に速くなるのだが、ある一定のファイルサイズを越えてしまうとキャッシュが無効となってしまう。 10GB のファイルではそのようなことが発生することは確認しているが、どれくらいの大きさからキャッシュが無効になるのか不明である。 キャッシュが無効になってしまうと、Blocked Read で実装した文字列検索は複数回実行するときに不利となる。 なぜこのようなことが起こるのか調査して、それが起こらないように実装する必要がある。