Mercurial > hg > Papers > 2014 > masakoha-sigos
changeset 6:515f8d6a972f
add benchmark
author | Masataka Kohagura <e085726@ie.u-ryukyu.ac.jp> |
---|---|
date | Sat, 19 Apr 2014 23:40:28 +0900 |
parents | b824fc3885be |
children | c2aa5573dd39 |
files | paper/benchmark.tex paper/conclusion.tex |
diffstat | 2 files changed, 47 insertions(+), 29 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/benchmark.tex Thu Apr 17 18:04:14 2014 +0900 +++ b/paper/benchmark.tex Sat Apr 19 23:40:28 2014 +0900 @@ -1,22 +1,19 @@ -\section{benchmark} -\label{section:benchmark} +\section{benchmark} \label{section:benchmark} -\subsection{実験環境} +例題で紹介した Word Count に Blocked Read を組み込み、1 GB のファイルを読み込み計測を行った。 +実験環境 \begin{itemize} \item Mac OS X 10.9.1 \item 2*2.66 GHz 6-Core Intel Xeon \item Memory 16GB 1333MHz DDR3 \item HHD 1TB -\item file size 10 GB \item CPU num 12 -\item Boyer-Moore String Search で pattern がいくつ含まれているか検索 -\item ファイルを読み込みから結果が返ってくるまでを測定 \end{itemize} \subsection{結果} -以下の表に実行結果を示す。 +以下の表に読み込み時間を含めた場合の実行結果を示す。 \begin{tiny} \begin{table}[ht] @@ -25,31 +22,58 @@ \small \begin{tabular}[t]{c|r} \hline - 読み込み方法 & 平均実行速度(s)\\ + 読み込み方法 & 実行速度(s)\\ \hline - mmap & 154.6 \\ + mmap & 15.875 \\ \hline - 一括 Read & 114.9 \\ + mmap (CPU num = 1)& 15.294 \\ \hline - Blocked Read \& SPE\_ANY & 106.0 \\ + 一括 Read & 12.520 \\ + \hline + 一括 Read (CPU num = 1)& 18.758 \\ \hline - Blocked Read \& IO\_0 & 99.2 \\ + Blocked Read \& SPE\_ANY & 14.028 \\ \hline - mmap (CPU num:2) & 106.2 \\ + Blocked Read \& IO\_0 & 10.295 \\ \hline \end{tabular} - \caption{実行結果} + \caption{読み込みを含めた実行結果} \end{center} \end{table} \end{tiny} -実験結果より、mmap より Blocked Read \& IO\_0 の実行速度が 36 \% 改善された。 -また、Blocked Read の CPU Type も SPE\_ANY から IO\_0 に変更することによって更に 4 \% の改善が見られた。 +また、キャッシュに入った場合での実行結果を以下に示す。 -\section{考察} -mmap より Blocked Read で実装したほうが速くなったが、これは mmap の読み込み方法が問題であると考える。 +\begin{tiny} + \begin{table}[ht] + \begin{center} + \label{table:result} + \small + \begin{tabular}[t]{c|r} + \hline + 読み込み方法 & 実行速度(s)\\ + \hline + mmap & 0.878 \\ + \hline + 一括 Read & 1.469 \\ + \hline + Blocked Read \& IO\_0 & 0.866 \\ + \hline + \end{tabular} + \caption{キャッシュに入った時の実行結果} + \end{center} + \end{table} +\end{tiny} -I/O を含む例題の場合、シングルコアでの逐次実行であれば、mmap や pread で実装しても、Task は 読み込みを行って文字列検索を行うというシンプルな動作になる。 -しかし、マルチコアの並列実行であれば、mmap で実装してしまうと、Task それぞれで読み込みを行ってしまうので競合が発生してしまう。 +読み込みを含めた場合の実験結果より、Blocked Read \& IO\_0 の実行速度が mmap と比較して 1.55 倍向上した。 +また、Blocked Read の CPU Type も SPE\_ANY から IO\_0 に変更することによって 1.36 倍向上した。 + +キャッシュに入った時は、mmap のほうが一括 Read と比較して 1.67 倍速くなる。そして、mmap と Blocked Read と mmap は、ほとんど同じ実行速度となった。 +\subsection{考察} -読み込みの競合が起こらないように Blocked Read にて読み込み部分と文字列検索部分を分けた結果、こちらのほうが速度が向上した。 +% mmap より Blocked Read で実装したほうが速くなったが、これは mmap の読み込み方法が問題であると考える。 +% +% I/O を含む例題の場合、シングルコアでの逐次実行であれば、mmap や pread で実装しても、Task は 読み込みを行って文字列検索を行うというシンプルな動作になる。 +% しかし、マルチコアの並列実行であれば、mmap で実装してしまうと、Task それぞれで読み込みを行ってしまうので競合が発生してしまう。 +% +% 読み込みの競合が起こらないように Blocked Read にて読み込み部分と文字列検索部分を分けた結果、こちらのほうが速度が向上した。
--- a/paper/conclusion.tex Thu Apr 17 18:04:14 2014 +0900 +++ b/paper/conclusion.tex Sat Apr 19 23:40:28 2014 +0900 @@ -1,4 +1,4 @@ -\subsection{まとめ} +\section{まとめと今後の課題} 本研究では、I/Oを含む Task の並列処理の動作の改善を行った。 ファイルを mmap でメモリを確保すると、文字列検索を行う Task が読み込みを行い、それが終了後に検索が行われる。 @@ -9,18 +9,12 @@ そのようなことが起こらないように、Cerium Task Manager に新しいデバイスの設定 IO\_0 というタイプを追加した。このデバイスは、他のデバイス設定よりも priority を高く設定しているので、このタイプ以外で起動する Task に割り込まれることが起こらなくなる。 これらを実装した結果、本研究では mmap で実装したときよりも 36 \% の動作改善が見られた。 -本研究を通して、I/O を含む Task の並列化の問題において、I/O の動作を改善する余地があると考える。 -\subsection{今後の課題} 本来読み込みを行ったファイルは、一度プログラムを実行したあとでもキャッシュとしてメモリ上にテキストがそのまま残っている。 キャッシュとは、使用頻度の高いデータを高速なデバイスに蓄えておくことによって読み込みのオーバーヘッドを少なくするための機能である。 -ハードディスクはメモリと比較すると読み込みが遅いので、ハードディスクからファイル読み込みを行うと、読み込みが速いメモリのほうに格納される。 -読み込んだファイルが再利用されるとき、ハードディスクからメモリに格納するという時間が無くなるので、2回目以降の実行結果は速くなる。 - mmap で実装を行うと、同じファイルに対して複数回検索を行うときに 2回目以降のプログラムの処理は速くなる。 -本研究では mmap で 10GB のファイルに対して文字列検索を行うと約150秒かかるが、2回目以降の実行速度に関しては、約7秒でプログラムが終了する。 - +それに対して、 Blocked Read も 2回目以降の実行速度は mmap と同様に速くなるのだが、ある一定のファイルサイズを越えてしまうとキャッシュが無効となってしまう。 10GB のファイルではそのようなことが発生することは確認しているが、どれくらいの大きさからキャッシュが無効になるのか不明である。