--- a/paper/appendix1.tex	Tue Feb 11 18:41:20 2014 +0900
+++ b/paper/appendix1.tex	Tue Feb 11 19:45:40 2014 +0900
@@ -32,9 +32,9 @@
 
 再起動後も有効にするためには, システムファイルの編集を行う. 
 
-/etc/security/limits.conf へ以下の記述を追加する. 
+/etc/security/limits.conf へソースコード\ref{limit}の記述を追加する. 
 
-\begin{lstlisting}[caption=リミットの設定の追加]
+\begin{lstlisting}[label=limit, caption=リミットの設定の追加]
  * soft nofile 200000
  * hard nofile 200000
 \end{lstlisting}
@@ -44,9 +44,10 @@
 このキューの長さの制限が小さいと, 同時にたくさんのコネクション要求がきた場合, 制限を超えた要求を拒否する. 
 listen キューや, その他の設定も含めてベンチマーク用にサーバの設定を変更する. 
 
-/etc/sysctl.conf に以下の記述を追加する. 
+/etc/sysctl.conf にソースコード\ref{sysctl}の記述を追加する. 
 
-\begin{lstlisting}[caption=システム設定の変更]
+\newpage
+\begin{lstlisting}[label=sysctl, caption=システム設定の変更]
 fs.file-max = 5000000
 net.core.netdev_max_backlog = 400000
 net.core.optmem_max = 10000000
@@ -72,9 +73,9 @@
 net.ipv4.tcp_tw_recycle = 1
 \end{lstlisting}
 
-ファイルを保存後, 設定を反映させるには以下のコマンドを実行する. 
+ファイルを保存後, 設定を反映させるにはソースコード\ref{sysctl2}のコマンドを実行する. 
 
-\begin{lstlisting}[caption=設定の反映]
+\begin{lstlisting}[label=sysctl2, caption=設定の反映]
 $ sudo sysctl -p /etc/sysctl.conf
 \end{lstlisting}
 
@@ -91,8 +92,8 @@
 また, livev を使うことで, モダンなポール・システムコールを利用し, 測定性能を向上できるといった特徴を持つ. 
 同様の性能測定ツールには, Apache Benchやhttprefが存在するが非力であり, ボトルネックとなってしまうため使用しない. 
 
-weighttp を起動するには, 以下の様にコマンドを入力する. 
-\begin{lstlisting}[caption=weighttpの起動]
+weighttp を起動するには, ソースコード\ref{weighttp}のコマンドを入力する. 
+\begin{lstlisting}[label=weighttp, caption=weighttpの起動]
 $ weighttp -n 1000000 -c 1000 -t 10 -k "http://bldsv12.cr.ie.u-ryukyu.ac.jp:3000"
 \end{lstlisting}
 

--- a/paper/benchmark/warp/warp.eps	Tue Feb 11 18:41:20 2014 +0900
+++ b/paper/benchmark/warp/warp.eps	Tue Feb 11 19:45:40 2014 +0900
@@ -1,7 +1,7 @@
 %!PS-Adobe-2.0 EPSF-2.0
 %%Title: warp.eps
 %%Creator: gnuplot 4.6 patchlevel 3
-%%CreationDate: Tue Feb 11 14:46:00 2014
+%%CreationDate: Tue Feb 11 19:38:44 2014
 %%DocumentFonts: (atend)
 %%BoundingBox: 50 50 410 302
 %%EndComments
@@ -433,7 +433,7 @@
   /Author (amothic)
 %  /Producer (gnuplot)
 %  /Keywords ()
-  /CreationDate (Tue Feb 11 14:46:00 2014)
+  /CreationDate (Tue Feb 11 19:38:44 2014)
   /DOCINFO pdfmark
 end
 } ifelse
@@ -648,6 +648,34 @@
 6947 4344 Crs
 6579 4598 Crs
 % End plot #2
+% Begin plot #3
+1.000 UP
+1.000 UL
+LT2
+0.00 0.00 0.00 C LCb setrgbcolor
+6296 4458 M
+(GHC 7.6.3) Rshow
+LT2
+0.00 0.00 0.00 C 6380 4458 M
+399 0 V
+938 914 M
+858 555 V
+859 417 V
+858 536 V
+859 409 V
+5230 1674 L
+859 -294 V
+6947 915 L
+938 914 Star
+1796 1469 Star
+2655 1886 Star
+3513 2422 Star
+4372 2831 Star
+5230 1674 Star
+6089 1380 Star
+6947 915 Star
+6579 4458 Star
+% End plot #3
 1.000 UL
 LTb
 938 4871 N

--- a/paper/benchmark/warp/warp.plt	Tue Feb 11 18:41:20 2014 +0900
+++ b/paper/benchmark/warp/warp.plt	Tue Feb 11 19:45:40 2014 +0900
@@ -5,4 +5,5 @@
 set xlabel "number of cpus"
 set ylabel "req/s"
 
-plot "online.dat" using 1:2 with linespoints linewidth 1 linecolor rgbcolor "red" title "online", "offline.dat" using 1:2 with linespoints linewidth 1 linecolor rgbcolor "blue" title "offline"
+plot "online.dat" using 1:2 with linespoints linewidth 1 linecolor rgbcolor "red" title "online", "offline.dat" using 1:2 with linespoints linewidth 1 linecolor rgbcolor "blue" title "offline", "ghc.dat" using 1:2 with linespoints linewidth 1 linecolor rgbcolor "black" title "GHC 7.6.3"
+

--- a/paper/chapter4.tex	Tue Feb 11 18:41:20 2014 +0900
+++ b/paper/chapter4.tex	Tue Feb 11 19:45:40 2014 +0900
@@ -49,7 +49,7 @@
 
 計測環境の構築方法については付録に記載する. 
 
-
+\clearpage
 \section{読み込みの性能計測}
 非破壊的木構造データベース Jungle を用いて, マルチコアプロセッサ上で並列に読み込みを行い, 線形に性能向上ができるか調査する. 
 
@@ -114,7 +114,7 @@
 非破壊的木構造データベース Jungle は 12 スレッドで 10.37 倍の性能向上が得ることができる.
 読み込みにおいて, スケールするデータベースであると言える.
 
-
+\clearpage
 \section{書き込みの性能計測}
 非破壊的木構造データベース Jungle を用いて, マルチコアプロセッサ上で並列に書き込みを行い, 線形に性能向上ができるか調査する. 
 
@@ -129,8 +129,10 @@
 
 CPUコア数を増やしていくと, 実行時間が短くなっていることが分かる. 
 シングルスレッドで実行した場合と比較して, 2 スレッドで 1.79 倍, 12 スレッドで 3.18 倍の性能向上が見られる. 
-OSの親和性機能を使った場合, 2 スレッドで 1.61 倍, 12 スレッドで 3.82 倍の性能向上が見られ, 4 スレッド以上では親和性機能を使ったほうが実行時間が短くなる.
-書き込みは, 読み込みと比べるとJungleへの木構造の登録作業があるため並列化率が下がり, 12スレッド時に3.82倍程度の性能向上率となる.
+OSの親和性機能を使った場合, 2 スレッドで 1.61 倍, 12 スレッドで 3.82 倍の性能向上が見られ, 4 スレッド以上では親和性機能を使ったほうが実行時間が短くなる. 
+また, 読み込みと同様に親和性機能を使った場合 24 スレッドでの実行時間が大幅に伸びる.
+
+書き込みは, 読み込みと比べるとJungleへの木構造の登録作業があるため性能向上率が下がる.
 
 \begin{table}[!htbp]
 \begin{center}
@@ -199,17 +201,18 @@
 ネットワークのボトルネックがどれぐらいあるのか調査するために, アクセスした際に "hello, world" という文字列を返すだけのプログラムを作成し測定する. 
 ネットワークを介さずに性能測定する場合, 性能測定ツール weighttp に 3 スレッド利用するため, Warp で利用するのは 8 スレッドまでとする.
 weighttpの設定は, リクエストの総数 100 万, 同時に接続するコネクションの数 1,000, 実行時のスレッド数 3, HTTP Keep-Alivesを有効とする. 
+また, 現在の安定版である 7.6.3 は IO マネージャーに問題があるが, どの程度影響があるか調べるためにGHC 7.6.3 でコンパイルし、ネットワークを介さない状態での測定も行う.
 結果を表\ref{tab:warp}に示す.
 
 \begin{table}[!htbp]
 \begin{center}
-\begin{tabular}{|c||r|r|} \hline
-  CPU数 & ネットワーク介す & ネットワークを介さない \\ \hline
-  1 & 44,008 req/s & 44,504 req/s \\\hline
-  2 & 57,396 req/s & 95,760 req/s \\\hline
-  4 & 60,593 req/s & 179,791 req/s \\\hline
-  6 & 57,159 req/s & 241,240 req/s \\\hline
-  8 & 59,697 req/s & 264,231 req/s \\\hline
+\begin{tabular}{|c||r|r|r|} \hline
+  CPU数 & ネットワーク介す & ネットワークを介さない & GHC 7.6.3\\ \hline
+  1 & 44,008 req/s & 44,504 req/s  & 31,602 req/s \\\hline
+  2 & 57,396 req/s & 95,760 req/s  & 69,265 req/s \\\hline
+  4 & 60,593 req/s & 179,791 req/s & 133,897 req/s \\\hline
+  6 & 57,159 req/s & 241,240 req/s & 83,131 req/s \\\hline
+  8 & 59,697 req/s & 264,231 req/s & 31,694 req/s \\\hline
 \end{tabular}
 \end{center}
 \caption{Warp の 性能測定結果}
@@ -223,6 +226,8 @@
 ネットワークを介さない場合は, 線形にスケールしている（図\ref{fig:warp_benchmark}）.
 ネットワークを介した場合, およそ 60,000 req/s 程度で頭打ちとなってしまっている.
 
+GHC 7.6.3 は, 5 スレッドあたりまでスケールするものの, それ以降遅くなり, 8スレッド実行時はシングルスレッドで実行した場合と変わらないといったバグが存在することがわかる.
+
 \begin{figure}[!htbp]
  \begin{center}
   \includegraphics[width=100mm]{./images/warp.pdf}
@@ -241,7 +246,7 @@
  \caption{実験環境}
  \label{fig:request}
 \end{figure}
-
+\newpage
 
 \subsection{読み込みと書き込み}
 \subsubsection{計測方法}
@@ -282,7 +287,7 @@
  \label{fig:bbs}
 \end{figure}
 
-\subsection{Javaを用いた非破壊的木構造データベースとの比較}
+\section{Javaを用いた非破壊的木構造データベースとの比較}
 非破壊的木構造データベースは, Haskell 版と Java 版が存在する. 
 Web 掲示板サービスを両方の言語で実装し, 比較を行う. 
 Haskell ではフロントエンドとして Warp を利用したが, Java では Jetty を利用する. 
@@ -313,6 +318,6 @@
 Java を用いた Jungle の実装は, 3390行で, Haskell の実装は 1/12 程度のサイズとなっている.
 
 コード行数が短くなった要因としては, Haskellが独自の再帰的データ構造の定義を言語としてサポートしていることや, 
-関数が参照透過性を持つため再利用が行いやすい上に, 関数を結合することが可能ということが考えられる.
+関数が参照透過性を持つため再利用が行いやすいということが考えられる.
 
 同じ機能を実装する場合でも, Haskell は Java と比較してコード行数が短くなり生産性が向上する. 

--- a/paper/conclusion.tex	Tue Feb 11 18:41:20 2014 +0900
+++ b/paper/conclusion.tex	Tue Feb 11 19:45:40 2014 +0900
@@ -9,18 +9,16 @@
 また, 型安全により実行時に型エラーによってプログラムが終了するといったことがない. 
 
 読み込みに関して 12 コアで実行した場合, 1 コアで実行した場合と比較して, 10.77 倍 という性能向上率が確認でき, マルチコアプロセッサの性能を引き出すことができた. 
-また, Web 掲示板サービスを開発し,  既存の Java の非破壊的木構造データベースを用いた掲示板実装との比較をおこない, 読み込みで 1.87 倍, 書き込みで 2.3 倍の性能が確認できた. 
+また, Web 掲示板サービスを開発し,  既存の Java の非破壊的木構造データベースを用いた掲示板実装との比較をおこない, 読み込みで 3.25 倍, 書き込みで 3.78 倍の性能が確認できた. 
 
 \section{今後の課題}
 非破壊的木構造データベース Jungle の今後の課題について述べる. 
 
 \subsubsection{書き込み処理の性能向上率の上昇}
-データベースへの書き込み処理において, 12 スレッド時で 3.86 倍の性能向上しか達成できていない. 
-はじめに, プログラムの変更をせずに, GHC の IO マネージャーの改善によりどの程度並列度が向上するのかを調査する必要がある. 
-GHC の IO マネージャーの影響度を計測した後, 変更処理の改善方法に調査する. 
-現在ソフトウェア・トランザクショナル・メモリを用いているが, 他のスレッドセーフな参照型を用いて性能改善が行えないか確認する. 
+データベースへの書き込み処理において, 12 スレッド時で 3.82 倍の性能向上となっている.
+現在ルートノードの管理には, ソフトウェア・トランザクショナル・メモリを用いているが, 他のスレッドセーフな参照型を用いて性能改善が行えないか確認する. 
 Haskell では, 様々なスレッドセーフな参照型が用意されている. 
-ロックが制限的だが, 高速なIORef, ロックの使えるMVarなどである. 
+ロックが制限的だが高速なIORef, 一般的なロックの使えるMVarなどである. 
 
 \subsubsection{分散データベースとしての実装}
 現在, 並列環境で実行できるが, 今後は分散データベースとして実行できるようにしたい. 

Binary file paper/images/warp.pdf has changed

--- a/paper/images/warp.xbb	Tue Feb 11 18:41:20 2014 +0900
+++ b/paper/images/warp.xbb	Tue Feb 11 19:45:40 2014 +0900
@@ -4,5 +4,5 @@
 %%HiResBoundingBox: 0.000000 0.000000 360.000000 252.000000
 %%PDFVersion: 1.4
 %%Pages: 1
-%%CreationDate: Tue Feb 11 14:49:50 2014
+%%CreationDate: Tue Feb 11 19:39:02 2014
 

Binary file paper/master_paper.pdf has changed