--- a/evaluations.tex	Fri Feb 12 13:10:57 2010 +0900
+++ b/evaluations.tex	Tue Feb 16 14:04:40 2010 +0900
@@ -45,7 +45,7 @@
 をサポートしてきた。しかし他のCPUに新しく対応するには多大な時間、労力
 が必要となる。
 GCCは現在、既に20を越えるCPUに対応しており、またOS毎のABIの差異も吸収
-可能である。これはGCCをコンパイラとすることに最大の利点である。
+可能である。これはGCCをコンパイラとすることの最大の利点である。
 
 またそれだけでなく、GCCは新しいアーキテクチャへの対応も早い。この特徴
 は、GCCがフロントエンドとバックエンドという形で言語実装とアーキテクチ
@@ -96,8 +96,8 @@
 での互換性がない。つまりGCCでコンパイルしたコードセグメントからmicro-c
 でコンパイルしたコードセグメントに継続することはできない。
 
-これはmicro-cでの軽量継続のABIが関数とはまったく違うものだからである。
-今回はtailcallを実装に用いたため、関数としての制限があり、micro-cの
+これはmicro-cでの軽量継続のABIが関数とはまったく異なるものだからである
+。今回はtailcallを実装に用いたため、関数としての制限があり、micro-cの
 ABIに合わせることはできなかった。
 
 この問題はGCCの欠点というわけではないが、CbCベースの共有ライブラリを生
@@ -125,7 +125,7 @@
 
 もう一つの比較対象にはmicro-cベースのコンパイラを用いる。
 さらにGCCでは最適化による効果も評価するため、
-\begin{inparaenum}[\itshape 1)\ttfamily]
+\begin{inparaenum}[\bfseries\itshape 1)\ttfamily]
   \item 最適化なし ``-O0''
   \item 速度最適化 ``-O2 -fomit-framepointer''
   \item サイズ最適化 ``-Os''
@@ -180,25 +180,24 @@
   \label{tab:speed-mc-vs-gcc}
 \end{table}
 
-実行ファイルのstrip前のファイルサイズを表\ref{tab:eval-nostrip}
-に、strip後のファイルサイズを表\ref{tab:eval-strip}に示す。
+実行ファイルstrip後のファイルサイズを表\ref{tab:eval-strip}に示す。
 
-\begin{table}[htpb]
-  \centering
-  \begin{tabular}{|c|c|c|c|c|c|} \hline
-    \multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ}  }
-              & \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{micro-c} \\ \cline{2-5}
-              & \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} &  \\ \cline{2-5}
-              & 速度最適化 & サイズ最適化 & 速度最適化 & サイズ最適化 & \\ \hline
-    x86/OS X  & 11100 & 11100 &  9804 &  9804 & 11136 \\ \hline
-    x86/Linux & 18444 & 17310 &  8216 &  8214 &  9844 \\ \hline
-    ppc/OS X  & 10392 & 10392 &  9172 &  9172 & 14396 \\ \hline
-    ppc/Linux & 25138 & 23876 & 13030 & 13028 & 15453 \\ \hline
-    ppc/PS3   & 22142 & 20452 &  9906 &  9672 & 15463 \\ \hline
-  \end{tabular}
-  \caption{実行ファイルのファイルサイズ比較 not stripped（単位: bytes）}
-  \label{tab:eval-nostrip}
-\end{table}
+%\begin{table}[htpb]
+  %\centering
+  %\begin{tabular}{|c|c|c|c|c|c|} \hline
+    %\multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ}  }
+              %& \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{micro-c} \\ \cline{2-5}
+              %& \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} &  \\ \cline{2-5}
+              %& 速度最適化 & サイズ最適化 & 速度最適化 & サイズ最適化 & \\ \hline
+    %x86/OS X  & 11100 & 11100 &  9804 &  9804 & 11136 \\ \hline
+    %x86/Linux & 18444 & 17310 &  8216 &  8214 &  9844 \\ \hline
+    %ppc/OS X  & 10392 & 10392 &  9172 &  9172 & 14396 \\ \hline
+    %ppc/Linux & 25138 & 23876 & 13030 & 13028 & 15453 \\ \hline
+    %ppc/PS3   & 22142 & 20452 &  9906 &  9672 & 15463 \\ \hline
+  %\end{tabular}
+  %\caption{実行ファイルのファイルサイズ比較 not stripped（単位: bytes）}
+  %\label{tab:eval-nostrip}
+%\end{table}
 \begin{table}[htpb]
   \centering
   \begin{tabular}{|c|c|c|c|} \hline
@@ -238,12 +237,12 @@
 \subsubsection{速度面}
 まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し
 ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、
-ppcでは5〜7倍もの差が生じている。
-ただしppcのこの以上な速度差は\ref{sec:impl-parallel}並列代入で示した様に、継続の引
-数を全て一時変数に入れていることが大きい。その場合最適化なしではすべて
-の引数を一度メモリに確保するので、その分逆に遅くなっているのだと考えら
-れる。しかしながら最適化を有効にすることでそのメモリへの一時変数の確保
-も解消されるということが分かった。
+ppcでは5〜7倍もの差が生じている。ただしppcのこの異常な速度差は
+\ref{sec:impl-parallel}並列代入で示した様に、継続の引数を全て一時変数
+に入れていることが大きい。その場合最適化なしではすべての引数を一度メモ
+リに確保するので、その分逆に遅くなっているのだと考えられる。しかしなが
+ら最適化を有効にすることでそのメモリへの一時変数の確保も解消されるとい
+うことが分かった。
 
 x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmicro-cを比べる
 と、 OS Xではmicro-cに比べて20\%ほど早くなった事が分かる。しかし逆に
@@ -315,13 +314,13 @@
 が分かる。この環境では速度面でも大きな差はなく、micro-cの精度の良さが
 わかる。
 
-デバグ情報のあり／なし／strip後との比較で大きな差が出ているのは全て
-Linux（PS3含む）である。Linuxでは実行ファイルのファイル形式にELFを用い
-ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい
-るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ
-ているのだと考えられる。
-Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された
-環境ではデバグが困難になることが考えられる。
+%デバグ情報のあり／なし／strip後との比較で大きな差が出ているのは全て
+%Linux（PS3含む）である。Linuxでは実行ファイルのファイル形式にELFを用い
+%ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい
+%るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ
+%ているのだと考えられる。
+%Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された
+%環境ではデバグが困難になることが考えられる。
 
 また興味深い特徴として、速度最適化とサイズ最適化の差がppc/PS3以外は全
 くないことも分かった。 サイズ最適化は速度最適化の最適化機能から、ファ
@@ -358,7 +357,7 @@
 分かった。
 
 また、それだけなら速度はほぼ同じ結果がでるところだが、ここではいずれの
-環境でも新しいバージョンの方が速い。15~20\%ほど高速化していることがわ
+環境でも新しいバージョンの方が速い。15--20\%ほど高速化していることがわ
 かる。これは本研究で行った改善の一つ、fastcallの影響である。