--- a/preliminary/final-thesis.tex	Mon Jun 15 05:14:53 2015 +0900
+++ b/preliminary/final-thesis.tex	Tue Jun 16 11:55:03 2015 +0900
@@ -51,24 +51,26 @@
 \label{fig:includeio}
 \end{figure}
 
-\section{並列処理向け I/O の設計と実装}
+\section{Design and implementation of parallel processing for I/O}
 
-\subsection{mmap での実装の問題点}
-先行研究では mmap によるファイルの読み込みを行っていた。
-mmap でファイルを読み込むタイミングは、mmap 関数が呼ばれたときではなく、mmap した領域に対して何らかのアクセスをしたときに初めてファイルが読み込まれる。
-つまり、分割された Task は文字列検索をすぐに行うのではなく、文字列検索を行おうとした時に初めてファイルが格納される。
-Task は複数一斉に実行されることが望ましいが、mmap ではそれぞれの Task で読み込みが起こってしまうため、I/O ネックによる Task の待ちが発生する。
+\subsection{problems implementation of mmap}
+In previous research we has done the reading of files in mmap.
+Timing for reading files in mmap , not when the mmap function was called , for the first time the file is read when you access something with it mmap regions.
+So divided Task is not to perform a string search immediately, the first time the file is stored in memory when it tries to string search .
+Task is desirably performed simultaneously .
+Since the reading is in mmap in each Task would happening , waiting Task by the I/O bottleneck occurs.
 
-\subsection{Blocked Read の設計と実装}
-Blocked Read とは、あるサイズずつで読み込む処理と、それらに文字列検索を行う処理を分離させるための実装方法である。
-この方法では、読み込み専用の Blocked Read と、文字列検索を行う Task Blocks を別々に生成し処理を行う。
-Read Task はファイル全体を一度に読み込むのではなく、ある程度の大きさで分割を行い、読み込みされ次第それぞれの文字列検索が行われる。
+\subsection{Design and implementation of Asynchronous read}
+Asynchronous read separate to a process to read certain size and to perform a string search .
+In this way , I do a read-only Asynchronous read, it was generated separately the Task Blocks to perform a string search processing .
 
-Task は 1つずつ起動すると、起動した Task でメモリを圧迫してしまうため、Task を複数まとめたブロック単位で起動を行う。
-この1つのブロックで処理されるテキストファイルを、Blocked Read で読み込んでいき、読み込みが終わったら読み込まれた範囲の Task Blocks を起動する。
-もし、Blocked Read で読み込まれる前にその範囲を担当する Task が起動してしまうと、正しい結果が返ってこない。
-それを防止するために、Task Blocks は必ず Blocked Read が行われてから起動するように wait をかけている。
-(図\ref{fig:blockedreadwait})
+Read Task is not to read the entire file at once , performs a split certain size , each character string search is performed as soon as they are read.
+Task When starting one by one, because it would compress memory in Task you start to perform the boot block summarizes multiple Task.
+
+A text file to be processed in this one block , and we read in the Asynchronous Read, to start the Task Blocks in the range that has been read when you are finished loading .
+If the Task, which is responsible for the range before it is read by the Asynchronous Read ends up starting, not return the correct results.
+To prevent it, Task Blocks are always Blocked Read and wears wait to start from taking place.
+(fig\ref{fig:blockedreadwait})
 
 \begin{figure}[htbp]
 \begin{center}
@@ -78,15 +80,15 @@
 \label{fig:blockedreadwait}
 \end{figure}
 
-\subsection{I/O 専用 thread の実装}
-Cerium Task Manager では Task 単位で CPU Type の設定を変更することができる。
-SPE\_ANY という Type を設定すると、Cerium Task Manager 側が自動的に CPU を割り振る。
-しかし、今回の実装でこの Type を使用してしまうと、Blocked Read Task に割り込んで Task が割り振られてしまう問題がある。
-その問題を解決するために、IO\_0 という I/O 専用の thread を実装した。
-この Thread は I/O を最優先に実行されるようにチューニングを行った。
-(図\ref{fig:io0})
+\subsection{Implementation I/O thread}
+It is possible to change the settings for the CPU Type in Cerium Task Manager In Task Unit.
+If you set the Type of SPE\_ANY, Cerium Task Manager side automatically allocates CPU.
+However, if you would use this Type in this implementation, there is a problem that the Task to interrupt the Blocked Read Task would have been allocated.
+In order to solve the problem, an implementation of the thread of the dedicated I/O of IO\_0.
+This Thread was tuned to run at the highest priority to the I/O.
+(fig\ref{fig:io0})
 %%
-%(図\ref{fig:speany})
+%(fig\ref{fig:speany})
 %
 %\begin{figure}[htbp]
 %\begin{center}
@@ -113,13 +115,11 @@
  \item Mac OS X Mavericks (10.9.1)
  \item HDD 1TB、Memory 16GB、CPU 2*2.66 GHz 6-Core Intel Xeon
  \item CPU NUM 12
- \item 10GB のファイルに対して Booye-Moore String Search をかけ、検索文字列がいくつ含まれているのかカウント
- \item 測定はファイルの読み込みから結果が返ってくるまでの時間
+ \item Is multiplied by the Booye-Moore String Search for the 10GB file , count what is included a number of search string
+ \item Time until the measurements returned results from reading the file
 \end{itemize}
 
 %以下の表\ref{table:result}に実行結果を示す。
-以下の表１に実行結果を示す。
-
 \begin{tiny}
   \begin{table}[ht]
     \begin{center}
@@ -144,16 +144,15 @@
 \end{tiny}
 
 %\ref{table:result}より、mmap より Blocked Read \& IO\_0 の実行速度が 36 \% 改善された。
-表１より、mmap より Blocked Read \& SPE\_ANY の実行速度が  31\% 改善された。
-また、Blocked Read の CPU Type も SPE\_ANY から IO\_0 に変更することによって更に 4 \% の改善が見られた。
-これより、I/O を含む並列処理を行う場合は、mmap で実装することによって自動的に読み込ませるのではなく、自分自身で読み込みを制御したほうが速くなることがわかる。
+From Table 1, the execution speed of Asynchronous Read \&SPE\_ANY has been improved 31\% from mmap.
+In addition, CPU Type of Asynchronous Read was also seen further 4\% improvement by changing from SPE\_ANY to IO\_0.
+From this , when performing parallel processing including I/O, instead of automatically to read by implementing in mmap, it is understood that better to control the reading in itself increases.
 
 \section{conclusion}
-mmap で I/O を含む Task を実装するとき、mmap した領域に対して何らかの処理が加わった時にしか読み込みが行わないので、それぞれの Task に読み込みを任せてしまうことになる。
-それを解決する方法として、Blocked Read と Task を並列に行う実装を行った。
-また、Blocked Read が、他の Task に割り込まれないように改善した結果、35 \% の実行速度の改善が見られた。
-本研究より、I/O を含む Task は、チューニング次第で更に改善する余地があると考える。
-
+When implementing the Task containing an I / O with mmap, because reading is not carried out only when some processing is applied with respect to the mmap regions , so that it would leave the loading on each Task.
+As a method to solve it, and we implemented that performs Asynchronous Read and Task in parallel .
+Also , Asynchronous Read is a result of improved so as not to be interrupted in another Task, 35 \% improvement in execution speed was observed .
+From this study , Task , including an I / O , it is considered that there is room to further improve depending tuning.
 
 \thispagestyle{fancy}
 \begin{thebibliography}{9}