--- a/paper/chapter4.tex	Sun Feb 02 07:10:55 2014 +0900
+++ b/paper/chapter4.tex	Sun Feb 02 07:43:11 2014 +0900
@@ -214,10 +214,7 @@
 
 CPUコア数を増やしていくと、実行時間が短くなっていることが分かる。
 シングルスレッドで実行した場合と比較して、2 スレッドで 1.55 倍、12 スレッドで 3.86 倍の性能向上が見られる。
-読み込みと比べ、書き込みは並列化率が下がり、性能向上率が低いことが分かる。
-書き込みはルートノードの更新作業が入る。
-GHC の IO マネージャーは、マルチスレッドでうまくスケールしないという問題があり、並列化率が下がっているのだと考えれる。
-GHCの次期バージョンではIO マネージャーが改善され、スケールするようになる見込みである。\cite{iomanager}
+読み込みと比べ、書き込みはJungleへの登録作業があるため並列化率が下がり、性能向上率が低いことが分かる。
 
 ハイパースレッディングは効果がなく、13 スレッド以上では実行時間が遅くなっている。
 
@@ -253,6 +250,10 @@
  \label{fig:benchmark_write}
 \end{figure}
 
+Jungle へ登録する際に他のスレッドから登録があった場合に、ソフトウェア・トランザクショナル・メモリが処理をやり直すため、並列度が下がっていると思われるが、GHCの問題も考えられる。
+GHC の IO マネージャーは、マルチスレッドでうまくスケールしないという問題があり、並列度が下がってしまう。
+GHCの次期バージョンではIO マネージャーが改善され、スケールするようになる見込みである。\cite{iomanager}
+
 非破壊的木構造データベース Jungle は、書き込みは並列化率が低くなってしまい並列実行に向いていない。
 読み込みが高速なため、書き込みより読み込みが多用されるシステムに向いているといえる。
 
@@ -356,10 +357,7 @@
 結果を表\ref{tab:warp}に示す。
 1 スレッドで実行した場合は、Jungle と組み合わせた掲示板より速い。
 しかしながら、スレッド数が増えていくと掲示板の読み込みとあまり結果が変わらなくなってしまう。
-この問題も、GHC の IO マネージャー改良で改善される可能性が高い。
-
-ウェブアプリケーションを用いて実験する場合、データベースだけがボトルネックとなるように負荷をかけるのは難しい。
-ただ単にデータを大きくするだけでは、文字列をHTMLに変換するコストが大きくなってしまうためである。
+Warpは、HTTP サーバのため IO 処理を多用する。この問題は、GHC の IO マネージャーの改良で改善される可能性が高い。
 
 \begin{table}[!htbp]
 \caption{掲示板を利用した読み込みの計測結果}
@@ -391,6 +389,9 @@
 \end{center}
 \end{table}
 
+ウェブアプリケーションを用いて実験する場合、データベースだけがボトルネックとなるように負荷をかけるのは難しい。
+ただ単にデータを大きくするだけでは、文字列をHTMLに変換するコストが大きくなってしまうためである。
+
 \subsection{書き込み}
 \subsubsection{計測方法}
 掲示板に対して書き込みを行い、負荷をかける。