Papers/2010/kent-master: evaluations.tex comparison

comparison evaluations.tex @ 7:8ef81ff8cb52

emended.

author	kent <kent@cr.ie.u-ryukyu.ac.jp>
date	Fri, 12 Feb 2010 13:10:57 +0900
parents	dfb89e32eea1
children	4b2af58b0302

comparison

equal deleted inserted replaced

-:b59d31966d7d
+:8ef81ff8cb52
 \chapter{評価・考察}
 \label{chp:eval}
 本章では本研究の評価を行う。
+\section{本研究での改善による成果}
+本研究では、2008年に実装されたGCCベースコンパイラの改善を行った。
+まずはその改善による成果をここで述べる。
+\begin{description}
+\item [並列代入] \hfill \\
+並列代入の改善により、これまで存在した軽量継続の際のバグが取り除か
+れた。特に引数で渡されたコードセグメントポインタへ継続する際に出て
+いたバグに対する影響が大きい。
+\item [環境付き継続の実装] \hfill \\
+この実装により、Cとの互換性が確保できた。これにより名実ともにCwC
+コンパイラとして完成したと言える。
+\item [PowerPCでの間接軽量継続] \hfill \\
+これまで実質的にはPowerPCでは使用不能であった。
+本研究室ではPS3を用いた研究も行っており、その研究ではPowerPCアーキ
+テクチャが必要となる。この問題の解決により、当研究室の提案する
+CeriumはCbCベースへの移行が可能になる。
+\item [プトロタイプ宣言の自動生成] \hfill \\
+GCCとmicro-cの間にある、コードセグメントの宣言に関する差異が、この
+自動生成によって改善された。これにより、これまでmicro-c用に作成さ
+れていたプログラムはほとんど修正することなく動く。
+\item [x86でのfastcall] \hfill \\
+未だに主流であるx86アーキテクチャ（x86\_64への移行は進みつつあるが
+）において、若干の速度低下が見られていたものを改善した。この測定に
+ついては\ref{sec:evaluation}節で行う。
+\end{description}
 \section{GCCを使うことの利点・欠点}
 \label{sec:merit}
-これまでCbCのコンパイルに使用してきたmc(micro-c)に対し、新しくGCCが
+これまでCbCのコンパイルに使用してきたmicro-cに対し、新しくGCCが
 CwCのフルセットとして使用可能となった。ここでGCCを用いることの利点と欠
 点について考察する。
 \subsection*{アーキテクチャ}
-mcにおいてはPPC,x86,MIPS,ARM,SPUなど、多数のCPUアーキテクチャをサポー
+micro-cにおいてはPPC, x86, MIPS, ARM, SPUなど、多数のCPUアーキテクチャ
-トしてきた。しかしあるCPUに新しく対応するには多大な時間、労力が必要と
+をサポートしてきた。しかし他のCPUに新しく対応するには多大な時間、労力
-なる。
+が必要となる。
 GCCは現在、既に20を越えるCPUに対応しており、またOS毎のABIの差異も吸収
 可能である。これはGCCをコンパイラとすることに最大の利点である。
 またそれだけでなく、GCCは新しいアーキテクチャへの対応も早い。この特徴
 は、GCCがフロントエンドとバックエンドという形で言語実装とアーキテクチ
 (instruction scheduling)などがある。
 とくに、プログラムにおいては類似した形の式(expression)を扱うことがよく
 あるため、共通式除去は非常に効果が高い。同様の効果は同じ式を保持する変
 数を用意することでも実現できるがソースコードの修正が必要になる。
-mcにはこの最適化は含まれていないため、複雑な計算式を含むプログラムにお
+micro-cにはこの最適化は含まれていないため、複雑な計算式を含むプログラムにお
 いてはGCCの方が良いコンパイル結果を示すものと考えられる。
 %\ref{sec:}の性能評価では最適化の効果についても測定する。
 \subsection*{デバッガ}
 \subsection*{関数呼出しの名残り}
 上記の利点に対し、GCCであるゆえの欠点も存在する。
 本研究による軽量継続制御の実装には\ref{chp:impl}章で説明したように関数
 の末尾最適化を利用した。それゆえコードセグメントのアセンブラ出力の命令
-列には一部関数呼び出し時のスタック処理が残ってしまうことが分かっている。
+列には関数呼び出し時のスタック処理が一部残ってしまうことが分かっている。
 特にレジスタの少ないアーキテクチャ、x86などではそれが顕著に現れる。
-mcではコードセグメントと関数は完全に別物として取り扱っており、この様な
+micro-cではコードセグメントと関数は完全に別物として取り扱っており、この様な
 スタック操作はコードセグメントには現れないため、このオーバヘッドがGCC
 では不利な点である。
 \subsection*{互換性、ABI}
-%これは最後の考察に入れよう
+また、同じく関数呼び出しの名残りから、GCCではmicro-cとのバイナリレベル
-ソースコードレベルでの互換性の問題がある。
+での互換性がない。つまりGCCでコンパイルしたコードセグメントからmicro-c
-また、継続制御のパラメタを
+でコンパイルしたコードセグメントに継続することはできない。
-% 関数宣言
-% 型推定
+これはmicro-cでの軽量継続のABIが関数とはまったく違うものだからである。
-% ABI、特にppc
+今回はtailcallを実装に用いたため、関数としての制限があり、micro-cの
+ABIに合わせることはできなかった。
-% 最適化
+この問題はGCCの欠点というわけではないが、CbCベースの共有ライブラリを生
-% SPUでのベクトル演算
+成・使用する場合には注意が必要となる。
-% gdb
-% architecture
-% 関数呼び出しのオーバヘッド
-% 互換性,ソースコード、ABI
+\section{性能評価}\label{sec:evaluation}
+次にコンパイラの性能評価を行う。
-\section{性能評価}
 \subsection{評価項目、比較対象}
 コンパイラの出力した実行ファイルを複数回実行し、その実効速度を測定する
 。CbCは実用的なプログラムの記述を目的としているので、プログラムの動作
 速度は性能の評価として妥当だと考えられる。
 またもう一つの項目として、出力した実行ファイルのファイルサイズも評価す
 る。一般的なプログラムではファイルサイズを気にすることは少ないが、CbC
 の用途には組み込みなども考えられているため、ファイルサイズの影響は大き
 い。比較する際はstripコマンドを用いてデバグ情報等を取り除いている。
-%SPUはm..
 実効速度、ファイルサイズの比較対象として2つ用意した。
 一つは過去の研究でのGCCベースコンパイラ、つまり今回の改善を含めてない
 ものである。こちらはGCCのバージョン4.2.3をベースとしている。
-もう一つの比較対象にはmicro-cベースのコンパイラ（以下mc）を用いる。
+もう一つの比較対象にはmicro-cベースのコンパイラを用いる。
 さらにGCCでは最適化による効果も評価するため、
 \begin{inparaenum}[\itshape 1)\ttfamily]
 \item 最適化なし ``-O0''
 \item 速度最適化 ``-O2 -fomit-framepointer''
 \item サイズ最適化 ``-Os''
 CbCの性能評価に適していると考えられる。クイックソートはCbCに先立ってC
 で実装し、参考文献\cite{bib:kinjo-2005}で紹介する手法を用いてCbCに変換
 した。このプログラムは付録\ref{apx:quicksort}に添付する。
 測定環境は両コンパイラが対応しているアーキテクチャ、OSから以下の5つの
-組み合わせ[CPUアーキテクチャ/OS種別]を選択した。
+組み合わせ[CPUアーキテクチャ/OS種別]を選択した。（ppcはPowerPCの意であ
+る）
 \begin{itemize}
 \item ppc/OS X
 \item ppc/linux
 \item ppc/linux on PS3
 \item x86/OS X
 \item x86/linux
 \end{itemize}
-なお、mcはmips,armにも対応しているが、現在その処理系が用意できなかった
+なお、micro-cはMIPS, ARMにも対応しているが、現在その処理系が用意できな
-ので割愛している。また、GCC-4.2.3ベースコンパイラはppcでは実行不能であ
+かったので割愛している。また、GCC-4.2.3ベースコンパイラはppcでは実行不
-ったためx86のみとなる。
+能であったためx86のみとなる。
 各評価マシンの詳細は付録\ref{sec:machine-specs}に掲載する。
 %GCCのコンパイルでは``-O2 -fomit-pointer''の最適化を付加して測定している。
 % noreturnもON.
 % -O2で約10秒になる要素数を選んだ方がいいかもしれない
 \begin{table}[htpb]
 \centering
 \begin{tabular}{|c|c|c|c|c|} \hline
 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ}  }
-& \multicolumn{3}{c|}{GCC} & \multirow{2}{*}{mc} \\ \cline{2-4}
+& \multicolumn{3}{c|}{GCC} & \multirow{2}{*}{micro-c} \\ \cline{2-4}
 &最適化なし&速度最適化&サイズ最適化&  \\ \hline
 x86/OS X  & 5.901 & 2.434 & 2.785 & 2.857 \\ \hline
 x86/Linux & 5.732 & 2.401 & 2.876 & 2.254 \\ \hline
 ppc/OS X  &14.875 & 2.146 & 2.170 & 4.811 \\ \hline
 ppc/Linux &19.793 & 3.955 & 4.013 & 6.454 \\ \hline
 ppc/PS3   &39.176 & 5.874 & 6.111 &11.121 \\ \hline
 \end{tabular}
-\caption{アーキテクチャ毎のGCCとmcの速度比較（単位: 秒）}
+\caption{アーキテクチャ毎のGCCとmicro-cの速度比較（単位: 秒）}
 \label{tab:speed-mc-vs-gcc}
 \end{table}
-次に実行ファイルのstrip前のファイルサイズを表\ref{tab:eval-nostrip}
+実行ファイルのstrip前のファイルサイズを表\ref{tab:eval-nostrip}
 に、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}{*}{mc} \\ \cline{2-5}
+& \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{micro-c} \\ \cline{2-5}
 & \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} &  \\ \cline{2-5}
-& -O2 & -Os & -O2 & -Os & \\ \hline
+& 速度最適化 & サイズ最適化 & 速度最適化 & サイズ最適化 & \\ \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{table}
 \begin{table}[htpb]
 \centering
 \begin{tabular}{|c|c|c|c|} \hline
 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ}  }
-& \multicolumn{2}{c|}{GCC} & \multirow{2}{*}{mc} \\ \cline{2-3}
+& \multicolumn{2}{c|}{GCC} & \multirow{2}{*}{micro-c} \\ \cline{2-3}
-& -O2 & -Os & \\ \hline
+& 速度最適化 & サイズ最適化 & \\ \hline
 x86/OS X  &  9176 &  9176 &  9172 \\ \hline
 x86/Linux &  5752 &  5752 &  5796 \\ \hline
 ppc/OS X  &  8576 &  8576 & 12664 \\ \hline
 ppc/Linux & 10068 & 10068 &  9876 \\ \hline
 ppc/PS3   &  6960 &  6728 &  8636 \\ \hline
 \end{tabular}
 \caption{実行ファイルのファイルサイズ比較 stripped（単位: bytes）}
 \label{tab:eval-strip}
 \end{table}
-最後に、本研究での実装GCC-4.4.2と以前のバージョンGCC-4.2.3との比較を表
+本研究での実装GCC-4.4.2と以前のバージョンGCC-4.2.3との比較を表
 \ref{tab:speed-old-vs-new}に示す。こちらはx86のみ、最適化も-Osは対応し
 ていない。
 \begin{table}[htpb]
 \centering
 \begin{tabular}{|c|c|c|c|c|} \hline
 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ}  }
 & \multicolumn{2}{c|}{CbC on GCC-4.4.2} &
 \multicolumn{2}{c|}{CbC on GCC-4.2.3} \\ \hline
-&  -O0  &  -O2  &  -O0  &  -O2  \\ \hline
+&  最適化なし  & 速度最適化 & 最適化なし & 速度最適化 \\ \hline
 x86/OS X  & 5.907 & 2.434 & 4.668 & 3.048 \\ \hline
 x86/Linux & 5.715 & 2.401 & 4.525 & 2.851 \\ \hline
 \end{tabular}
 \caption{GCC-4.2.3ベースとGCC-4.4.2ベースの速度比較（単位: 秒）}
 \label{tab:speed-old-vs-new}
 \subsection{評価結果考察}
 % stripするとx86はサイズに変化がない
 \subsubsection{速度面}
-まずは速度面からこの測定結果を考察する。
 まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し
 ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、
 ppcでは5〜7倍もの差が生じている。
 ただしppcのこの以上な速度差は\ref{sec:impl-parallel}並列代入で示した様に、継続の引
 数を全て一時変数に入れていることが大きい。その場合最適化なしではすべて
 の引数を一度メモリに確保するので、その分逆に遅くなっているのだと考えら
 れる。しかしながら最適化を有効にすることでそのメモリへの一時変数の確保
 も解消されるということが分かった。
-x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmcを比べると、
+x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmicro-cを比べる
-OS Xではmcに比べて20\%ほど早くなった事が分かる。しかし逆にLinux環境で
+と、 OS Xではmicro-cに比べて20\%ほど早くなった事が分かる。しかし逆に
-は6\%の速度低下が示された。どちらにしてもppcほどの良い結果ではない。こ
+Linux環境では6\%の速度低下が示された。どちらにしてもppcほどの良い結果
-れは自由に使えるレジスタが極めて少ないというx86の特殊なアーキテクチャ
+ではない。これは自由に使えるレジスタが極めて少ないというx86の特殊なア
-が要因だと考えられる。そのためGCCの最適化が十分に機能できなかった可能
+ーキテクチャが要因だと考えられる。そのためGCCの最適化が十分に機能でき
-性がある。この6\%の差は実用レベルでは問題なく、プログラムの構成によっ
+なかった可能性がある。この6\%の差は実用レベルでは問題なく、プログラム
-ては結果は逆転する事も十分にある。
+の構成によっては結果は逆転する事も十分にある。
 ppcにおいてはどのオペレーティングシステムでも、速度最適化を使ったGCCは
-mcに比べて早い事が分かる。いずれも約2倍、もしくはそれ以上に速度が向上
+micro-cに比べて早い事が分かる。いずれも約2倍、もしくはそれ以上に速度が
-している。これはGCCの最適化機構が十分に働いている要因が大きい。
+向上している。これはGCCの最適化機構が十分に働いている要因が大きい。
 \subsubsection{アセンブラ比較}
 実際に出力されたアセンブラから速度向上の要因を確かめるため、quicksort
 プログラムで使用されているコードセグメントを一つ例に挙げる。CbCのプロ
 グラムソースがコード \ref{code:divider-e}である。このコードセグメント
-の速度最適化を使ったGCCによる出力がコード\ref{code:divider-e-gcc}、mc
+の速度最適化を使ったGCCによる出力がコード\ref{code:divider-e-gcc}、
-による出力がコード \ref{code:divider-e-mc}である。
+micro-c による出力がコード \ref{code:divider-e-mc}である。どちらもアー
-どちらもアーキテクチャはppcである。
+キテクチャはppcである。
-%まずどのアーキテクチャにおいてもgccの最適化の効果が大きいことが分かる
-%。 x86では約2.5倍、ppcでは4~7倍もの差が生じている。ppcの方で異様に効果
-%が高いように見えるのは、関数やコードセグメントの引数渡しがレジスタベー
-%スのため、最適化なしの場合には無駄なメモリアクセスが生じているためであ
-%る。
-%x86はOS XとLinuxの環境で測定を行った。OS Xではmcに比べて20\%ほど早くな
-%ったことが分かる。しかし逆にLinux環境では6\%の速度低下が示された。
-%どちらにおいてもppcほどの良い結果ではない。これは自由に使えるレジスタ
-%が極めて少ないというx86の特殊なアーキテクチャが要因だと考えられる。そ
-%のためにgccの最適化が十分に働かなかった可能性がある。逆に言うとmcが高
-%いレベルでx86のアセンブラ命令を実行しているともとれる。この6\%の差は実
-%用レベルでは問題なく、プログラムの構成によっては結果は逆転する事も十分
-%にある。
-%ppcではどのオペレーティングシステムでもmcに比べてgccが早いことが分かる
-%。いずれも約2倍近くあるいはそれ以上に速度が向上している。これはgccの最
-%適化機構が十分に働いている要因が大きい。
-%\subsubsection{アセンブラ比較}
-%比較のため、quicksortプログラムで使われているコードセグメントを一つ例
-%にあげる。 CbCのソースがコード\ref{code:divider_s}、そのコードセグメン
-%トのgccによる出力がコード\ref{code:divider_s_gcc}、mcによる出力がコー
-%ド \ref{code:divider_s_mc} である。
-%
 \lstinputlisting[
 caption=quicksortプログラムで使われているコードセグメント,
 label=code:divider-e]
 {sources/divider-e.cbc}
 \begin{minipage}[t]{.45\textwidth}
 {sources/divider-e-gcc.asm}
 \end{minipage}
 \hfill
 \begin{minipage}[t]{.45\textwidth}
 \lstinputlisting[
-caption=divider\_eのmcによる出力(ppc),
+caption=divider\_eのmicro-cによる出力(ppc),
 label=code:divider-e-mc]
 {sources/divider-e-mc.asm}
 \end{minipage}
-もっとも比較しやすい箇所は\verb|e-1|の処理である。
+もっとも比較しやすい箇所は\verb|e-1|の処理である。コード
-コード\ref{code:divider-e-gcc}のGCCではこれを1命令の\verb|addi 5,5,-1|
+\ref{code:divider-e-gcc}のGCCではこれを1命令の\verb|addi 5,5,-1| で行
-で行っている。 mcではこれが\verb|mr, addi, mr|という3命令になっている
+っている。 micro-cではこれが\verb|mr, addi, mr|という3命令になっている
 。これは変数\verb|s|の値を一度別のレジスタに移して計算するという処理で
 ある。この様な細かい命令の展開が速度に差が出る要因である。
 またこのppcのアセンブラからも、x86での速度差が少ないことが頷ける。引数
 のほとんどをメモリに格納するx86では、計算のために一度レジスタに格納し
 ないといけないことから、この命令は結局3命令になるはずであり、実際にx86
-ではGCC,mc共にそのようなコードが出力されていた。
+ではGCC, micro-c共にそのようなコードが出力されていた。
 この結果より、CbCで記述されたプログラムではレジスタが多い方が実効速度
 の面で有利であるということが分る。これは他のコンパイラ言語でも同じ事が
 言えるが、（手続きやメソッドにおける）前の環境を保持する必要がないCbC
 ではその影響がより強い。
 実行ファイルのファイルサイズは組み込み用途のプログラムには重要な要素と
 なる。多くの場合、組み込み機器では大容量のメモリは用意されておらず、
 OSも存在しないため仮想記憶の概念がない。そのためメモリに乗り切らないプ
 ログラムはそもそも実行不能である。
-まず、評価の主な特徴として、strip後のファイルサイズ\ref{tab:eval-strip}
+まず、評価の主な特徴として、strip後のファイルサイズ
-をみると、x86ではmcとGCCでほとんど差がない事が分かる。この環境では速度
+\ref{tab:eval-strip} をみると、x86ではmicro-cとGCCでほとんど差がない事
-面でも大きな差はなく、mcの精度の良さがわかる。
+が分かる。この環境では速度面でも大きな差はなく、micro-cの精度の良さが
+わかる。
 デバグ情報のあり／なし／strip後との比較で大きな差が出ているのは全て
 Linux（PS3含む）である。Linuxでは実行ファイルのファイル形式にELFを用い
 ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい
 るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ
 ているのだと考えられる。
 Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された
 環境ではデバグが困難になることが考えられる。
-また興味深い特徴として、-O2と-Osの差がppc/PS3以外は全くないことも分か
+また興味深い特徴として、速度最適化とサイズ最適化の差がppc/PS3以外は全
-った。 -Osは-O2の最適化機能から、ファイルサイズが大きくなるものを除外
+くないことも分かった。 サイズ最適化は速度最適化の最適化機能から、ファ
-したものである。評価結果には-Osによるファイルサイズの減少はほとんどな
+イルサイズが大きくなるものを除外したものである。評価結果にはサイズ最適
-く、しかし速度は少々遅くなっている。このことからCbCによるプログラムで
+化によるファイルサイズの減少はほとんどなく、しかし速度は少々遅くなって
-は-Osを用いる必要はなく、-O2で十分であることが分かった。
+いる。このことからCbCによるプログラムではサイズ最適化を用いる必要はな
+く、速度最適化で十分であることが分かった。
 % ELF, Mach-O
 % o OS Xはデバグ情報が少ない。逆か、ELFが多いのか
 % o x86でほぼ同じサイズ
-%\section{CbCでのプログラミング}
-% TODO:
 \section{メンテナンス性の向上に関する取り組み}\label{sec:mentainance}
 本研究室ではこれまでCbCコンパイラとしてmicro-cを利用していた。このコン
 パイラはベースとなるmicro-cには依存せずに、ほぼ独立な開発を続けている。
 これに対しGCCは現在も精力的に開発が続けられており、年数回のアップデー
 トではバグの除去や最適化の改善などが行われている。
 そのためCbCコンパイラでもそのリリースに沿ってアップデートすることが望
 ましく、実際に今回の改善の際にも2010年1月現在での最新リリースである
-4.4.2をベースとしている。
+4.4.2をベースとして行い、本稿執筆中に4.4.3へのアップデートが行われた。
 しかしアップデートの度に新しいソースコードを書き換えるのは無理があり、
 現実的ではない。最良の方法はGCCの正式な機能として開発リポジトリにマー
 ジしてもらうことだが、現段階ではそこには至っていない。
 こちらがCbCに関するメインの開発環境となる。図\ref{fig:gcc-repository}
 では中央と右のラインがそのリポジトリを表している。
 \begin{figure}[htpb]
 \begin{center}
-\includegraphics[width=.4\textwidth]{figures/gcc-repository.eps}
+\includegraphics[width=.7\textwidth]{figures/gcc-repository.eps}
 \end{center}
 \caption{CbCコンパイラ開発でのリポジトリ管理（左が本家のリリースタイ
 ムライン、中央がGCC-copy、右がCbCの開発用リポジトリのタイムライン）}
 \label{fig:gcc-repository}
 \end{figure}
 \begin{itemize}
 \item GCC-copyリポジトリにて
 \begin{enumerate}
 \item GCC-copyリポジトリ中のファイル全てを消す（バージョン管理情
 報以外）
-\item gcc-core-4.4.3.tar.gzを展開し、全ファイルをGCC-copyに追加
+\item gcc-core-{\tt\it version}.tar.gzを展開し、全ファイルをGCC-copyに追加
 \item \verb|hg status|で追加ファイル、削除ファイルを確認
 \item コミット
-\item gcc-4.4.3タグの追加
+\item gcc-{\tt\it version}タグの追加
 \end{enumerate}
 \item CbConGCCリポジトリにて
 \begin{enumerate}
 \item GCC-copyから\verb|pull|.
 \item \verb|hg merge|でマージ実行
 \item 衝突のあったファイルを修正
 \item 実際にビルドしてテストファイルが動くことを確認
 \item コミット
-\item cbc-4.4.3タグの追加
+\item cbc-{\tt\it version}タグの追加
 \end{enumerate}
 \end{itemize}
 以上でアップデートが完了する。
 \subsection{このリポジトリ管理方法の評価}
-実際にこのリポジトリ管理方法を用いてアップデートを行った。この作業では
+実際にこのリポジトリ管理方法を用いてアップデートを行った。この評価では
 バージョン 4.4.0から4.4.2へのアップデートと、4.4.2から4.4.3へのアップ
-デートである。
+デートを行った。
 アップデートの際に何らかの問題が生じるのはCbConGCCリポジトリでの衝突フ
 ァイルの修正だけである。4.4.3へのアップデートでは特になにも衝突するこ
 とはなかったが、4.4.2ではある関数の引数が変わっており、その修正に手作
 業を要した。しかし複雑な作業はこの衝突ファイルの修正だけに抑えられる。

Mercurial > hg > Papers > 2010 > kent-master

comparison evaluations.tex @ 7:8ef81ff8cb52