Mercurial > hg > Papers > 2010 > kent-master
comparison paper/evaluations.tex @ 10:3d9addf62d0b
organized repository.
author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 16 Feb 2010 14:35:36 +0900 |
parents | evaluations.tex@4b2af58b0302 |
children |
comparison
equal
deleted
inserted
replaced
9:ae0a3666f7f9 | 10:3d9addf62d0b |
---|---|
1 \chapter{評価・考察} | |
2 \label{chp:eval} | |
3 | |
4 本章では本研究の評価を行う。 | |
5 | |
6 | |
7 \section{本研究での改善による成果} | |
8 本研究では、2008年に実装されたGCCベースコンパイラの改善を行った。 | |
9 まずはその改善による成果をここで述べる。 | |
10 | |
11 \begin{description} | |
12 \item [並列代入] \hfill \\ | |
13 並列代入の改善により、これまで存在した軽量継続の際のバグが取り除か | |
14 れた。特に引数で渡されたコードセグメントポインタへ継続する際に出て | |
15 いたバグに対する影響が大きい。 | |
16 \item [環境付き継続の実装] \hfill \\ | |
17 この実装により、Cとの互換性が確保できた。これにより名実ともにCwC | |
18 コンパイラとして完成したと言える。 | |
19 \item [PowerPCでの間接軽量継続] \hfill \\ | |
20 これまで実質的にはPowerPCでは使用不能であった。 | |
21 | |
22 本研究室ではPS3を用いた研究も行っており、その研究ではPowerPCアーキ | |
23 テクチャが必要となる。この問題の解決により、当研究室の提案する | |
24 CeriumはCbCベースへの移行が可能になる。 | |
25 \item [プトロタイプ宣言の自動生成] \hfill \\ | |
26 GCCとmicro-cの間にある、コードセグメントの宣言に関する差異が、この | |
27 自動生成によって改善された。これにより、これまでmicro-c用に作成さ | |
28 れていたプログラムはほとんど修正することなく動く。 | |
29 \item [x86でのfastcall] \hfill \\ | |
30 未だに主流であるx86アーキテクチャ(x86\_64への移行は進みつつあるが | |
31 )において、若干の速度低下が見られていたものを改善した。この測定に | |
32 ついては\ref{sec:evaluation}節で行う。 | |
33 \end{description} | |
34 | |
35 \section{GCCを使うことの利点・欠点} | |
36 \label{sec:merit} | |
37 | |
38 これまでCbCのコンパイルに使用してきたmicro-cに対し、新しくGCCが | |
39 CwCのフルセットとして使用可能となった。ここでGCCを用いることの利点と欠 | |
40 点について考察する。 | |
41 | |
42 \subsection*{アーキテクチャ} | |
43 | |
44 micro-cにおいてはPPC, x86, MIPS, ARM, SPUなど、多数のCPUアーキテクチャ | |
45 をサポートしてきた。しかし他のCPUに新しく対応するには多大な時間、労力 | |
46 が必要となる。 | |
47 GCCは現在、既に20を越えるCPUに対応しており、またOS毎のABIの差異も吸収 | |
48 可能である。これはGCCをコンパイラとすることの最大の利点である。 | |
49 | |
50 またそれだけでなく、GCCは新しいアーキテクチャへの対応も早い。この特徴 | |
51 は、GCCがフロントエンドとバックエンドという形で言語実装とアーキテクチ | |
52 ャを分離していることからくる。一般的に新しいCPUアーキテクチャが開発さ | |
53 れた場合にはその開発者自身がGCCにコミットすることが多いため、組み込み | |
54 用途を目的の一つとするCbCではよりその強みがます。 | |
55 | |
56 \subsection*{最適化の恩恵} | |
57 GCCは豊富な最適化機構を備えている。 | |
58 代表的な最適化だけでもループ最適化、分岐スレッディング(jump threading) | |
59 、共通式除去(common subexpression elimination)、命令スケジューリング | |
60 (instruction scheduling)などがある。 | |
61 | |
62 とくに、プログラムにおいては類似した形の式(expression)を扱うことがよく | |
63 あるため、共通式除去は非常に効果が高い。同様の効果は同じ式を保持する変 | |
64 数を用意することでも実現できるがソースコードの修正が必要になる。 | |
65 micro-cにはこの最適化は含まれていないため、複雑な計算式を含むプログラムにお | |
66 いてはGCCの方が良いコンパイル結果を示すものと考えられる。 | |
67 | |
68 %\ref{sec:}の性能評価では最適化の効果についても測定する。 | |
69 | |
70 \subsection*{デバッガ} | |
71 これまでCbCにはデバッガが存在しなかった。デバッガの実装には出力するア | |
72 センブラに行番号や変数名、関数名などの情報を付加する必要があるが、GCC | |
73 は標準でこれを行っている。そのためCのデバッガとして広く一般的に使われ | |
74 ている gdbをそのままCbCのデバッガとして使用することが可能であり、ソフ | |
75 トウェア開発の大きな助力となる。 | |
76 | |
77 %ただし継続制御では``next''コマンドが使いづらいなどの操作性の問題がいく | |
78 %つか確認している。これらは | |
79 | |
80 % | |
81 \subsection*{関数呼出しの名残り} | |
82 上記の利点に対し、GCCであるゆえの欠点も存在する。 | |
83 | |
84 本研究による軽量継続制御の実装には\ref{chp:impl}章で説明したように関数 | |
85 の末尾最適化を利用した。それゆえコードセグメントのアセンブラ出力の命令 | |
86 列には関数呼び出し時のスタック処理が一部残ってしまうことが分かっている。 | |
87 特にレジスタの少ないアーキテクチャ、x86などではそれが顕著に現れる。 | |
88 | |
89 micro-cではコードセグメントと関数は完全に別物として取り扱っており、この様な | |
90 スタック操作はコードセグメントには現れないため、このオーバヘッドがGCC | |
91 では不利な点である。 | |
92 | |
93 | |
94 \subsection*{互換性、ABI} | |
95 また、同じく関数呼び出しの名残りから、GCCではmicro-cとのバイナリレベル | |
96 での互換性がない。つまりGCCでコンパイルしたコードセグメントからmicro-c | |
97 でコンパイルしたコードセグメントに継続することはできない。 | |
98 | |
99 これはmicro-cでの軽量継続のABIが関数とはまったく異なるものだからである | |
100 。今回はtailcallを実装に用いたため、関数としての制限があり、micro-cの | |
101 ABIに合わせることはできなかった。 | |
102 | |
103 この問題はGCCの欠点というわけではないが、CbCベースの共有ライブラリを生 | |
104 成・使用する場合には注意が必要となる。 | |
105 | |
106 | |
107 | |
108 | |
109 \section{性能評価}\label{sec:evaluation} | |
110 次にコンパイラの性能評価を行う。 | |
111 | |
112 \subsection{評価項目、比較対象} | |
113 コンパイラの出力した実行ファイルを複数回実行し、その実効速度を測定する | |
114 。CbCは実用的なプログラムの記述を目的としているので、プログラムの動作 | |
115 速度は性能の評価として妥当だと考えられる。 | |
116 | |
117 またもう一つの項目として、出力した実行ファイルのファイルサイズも評価す | |
118 る。一般的なプログラムではファイルサイズを気にすることは少ないが、CbC | |
119 の用途には組み込みなども考えられているため、ファイルサイズの影響は大き | |
120 い。比較する際はstripコマンドを用いてデバグ情報等を取り除いている。 | |
121 | |
122 実効速度、ファイルサイズの比較対象として2つ用意した。 | |
123 一つは過去の研究でのGCCベースコンパイラ、つまり今回の改善を含めてない | |
124 ものである。こちらはGCCのバージョン4.2.3をベースとしている。 | |
125 | |
126 もう一つの比較対象にはmicro-cベースのコンパイラを用いる。 | |
127 さらにGCCでは最適化による効果も評価するため、 | |
128 \begin{inparaenum}[\bfseries\itshape 1)\ttfamily] | |
129 \item 最適化なし ``-O0'' | |
130 \item 速度最適化 ``-O2 -fomit-framepointer'' | |
131 \item サイズ最適化 ``-Os'' | |
132 \end{inparaenum} | |
133 についてもそれぞれ比較する。 | |
134 | |
135 \subsection{評価手法と環境} | |
136 実行するプログラムとして、クイックソートのテストプログラムを作成した。 | |
137 クイックソートは再帰呼び出しを伴うため、スタック操作が必須となる。その | |
138 ためより様々な状態でコードセグメントへの継続制御が使用されることになり、 | |
139 CbCの性能評価に適していると考えられる。クイックソートはCbCに先立ってC | |
140 で実装し、参考文献\cite{bib:kinjo-2005}で紹介する手法を用いてCbCに変換 | |
141 した。このプログラムは付録\ref{apx:quicksort}に添付する。 | |
142 | |
143 測定環境は両コンパイラが対応しているアーキテクチャ、OSから以下の5つの | |
144 組み合わせ[CPUアーキテクチャ/OS種別]を選択した。(ppcはPowerPCの意であ | |
145 る) | |
146 \begin{itemize} | |
147 \item ppc/OS X | |
148 \item ppc/linux | |
149 \item ppc/linux on PS3 | |
150 \item x86/OS X | |
151 \item x86/linux | |
152 \end{itemize} | |
153 なお、micro-cはMIPS, ARMにも対応しているが、現在その処理系が用意できな | |
154 かったので割愛している。また、GCC-4.2.3ベースコンパイラはppcでは実行不 | |
155 能であったためx86のみとなる。 | |
156 | |
157 各評価マシンの詳細は付録\ref{sec:machine-specs}に掲載する。 | |
158 | |
159 %GCCのコンパイルでは``-O2 -fomit-pointer''の最適化を付加して測定している。 | |
160 % noreturnもON. | |
161 % x86ではfastcallもON, | |
162 | |
163 \subsection{評価結果} | |
164 実効速度の測定結果を表\ref{tab:speed-mc-vs-gcc}に示す。 | |
165 ただし環境毎にCPU速度は異なるので、上下の比較には意味はない。 | |
166 % -O2で約10秒になる要素数を選んだ方がいいかもしれない | |
167 \begin{table}[htpb] | |
168 \centering | |
169 \begin{tabular}{|c|c|c|c|c|} \hline | |
170 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | |
171 & \multicolumn{3}{c|}{GCC} & \multirow{2}{*}{micro-c} \\ \cline{2-4} | |
172 &最適化なし&速度最適化&サイズ最適化& \\ \hline | |
173 x86/OS X & 5.901 & 2.434 & 2.785 & 2.857 \\ \hline | |
174 x86/Linux & 5.732 & 2.401 & 2.876 & 2.254 \\ \hline | |
175 ppc/OS X &14.875 & 2.146 & 2.170 & 4.811 \\ \hline | |
176 ppc/Linux &19.793 & 3.955 & 4.013 & 6.454 \\ \hline | |
177 ppc/PS3 &39.176 & 5.874 & 6.111 &11.121 \\ \hline | |
178 \end{tabular} | |
179 \caption{アーキテクチャ毎のGCCとmicro-cの速度比較(単位: 秒)} | |
180 \label{tab:speed-mc-vs-gcc} | |
181 \end{table} | |
182 | |
183 実行ファイルstrip後のファイルサイズを表\ref{tab:eval-strip}に示す。 | |
184 | |
185 %\begin{table}[htpb] | |
186 %\centering | |
187 %\begin{tabular}{|c|c|c|c|c|c|} \hline | |
188 %\multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | |
189 %& \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{micro-c} \\ \cline{2-5} | |
190 %& \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} & \\ \cline{2-5} | |
191 %& 速度最適化 & サイズ最適化 & 速度最適化 & サイズ最適化 & \\ \hline | |
192 %x86/OS X & 11100 & 11100 & 9804 & 9804 & 11136 \\ \hline | |
193 %x86/Linux & 18444 & 17310 & 8216 & 8214 & 9844 \\ \hline | |
194 %ppc/OS X & 10392 & 10392 & 9172 & 9172 & 14396 \\ \hline | |
195 %ppc/Linux & 25138 & 23876 & 13030 & 13028 & 15453 \\ \hline | |
196 %ppc/PS3 & 22142 & 20452 & 9906 & 9672 & 15463 \\ \hline | |
197 %\end{tabular} | |
198 %\caption{実行ファイルのファイルサイズ比較 not stripped(単位: bytes)} | |
199 %\label{tab:eval-nostrip} | |
200 %\end{table} | |
201 \begin{table}[htpb] | |
202 \centering | |
203 \begin{tabular}{|c|c|c|c|} \hline | |
204 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | |
205 & \multicolumn{2}{c|}{GCC} & \multirow{2}{*}{micro-c} \\ \cline{2-3} | |
206 & 速度最適化 & サイズ最適化 & \\ \hline | |
207 x86/OS X & 9176 & 9176 & 9172 \\ \hline | |
208 x86/Linux & 5752 & 5752 & 5796 \\ \hline | |
209 ppc/OS X & 8576 & 8576 & 12664 \\ \hline | |
210 ppc/Linux & 10068 & 10068 & 9876 \\ \hline | |
211 ppc/PS3 & 6960 & 6728 & 8636 \\ \hline | |
212 \end{tabular} | |
213 \caption{実行ファイルのファイルサイズ比較 stripped(単位: bytes)} | |
214 \label{tab:eval-strip} | |
215 \end{table} | |
216 | |
217 本研究での実装GCC-4.4.2と以前のバージョンGCC-4.2.3との比較を表 | |
218 \ref{tab:speed-old-vs-new}に示す。こちらはx86のみ、最適化も-Osは対応し | |
219 ていない。 | |
220 \begin{table}[htpb] | |
221 \centering | |
222 \begin{tabular}{|c|c|c|c|c|} \hline | |
223 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | |
224 & \multicolumn{2}{c|}{CbC on GCC-4.4.2} & | |
225 \multicolumn{2}{c|}{CbC on GCC-4.2.3} \\ \hline | |
226 & 最適化なし & 速度最適化 & 最適化なし & 速度最適化 \\ \hline | |
227 x86/OS X & 5.907 & 2.434 & 4.668 & 3.048 \\ \hline | |
228 x86/Linux & 5.715 & 2.401 & 4.525 & 2.851 \\ \hline | |
229 \end{tabular} | |
230 \caption{GCC-4.2.3ベースとGCC-4.4.2ベースの速度比較(単位: 秒)} | |
231 \label{tab:speed-old-vs-new} | |
232 \end{table} | |
233 | |
234 | |
235 \subsection{評価結果考察} | |
236 % stripするとx86はサイズに変化がない | |
237 \subsubsection{速度面} | |
238 まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し | |
239 ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、 | |
240 ppcでは5〜7倍もの差が生じている。ただしppcのこの異常な速度差は | |
241 \ref{sec:impl-parallel}並列代入で示した様に、継続の引数を全て一時変数 | |
242 に入れていることが大きい。その場合最適化なしではすべての引数を一度メモ | |
243 リに確保するので、その分逆に遅くなっているのだと考えられる。しかしなが | |
244 ら最適化を有効にすることでそのメモリへの一時変数の確保も解消されるとい | |
245 うことが分かった。 | |
246 | |
247 x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmicro-cを比べる | |
248 と、 OS Xではmicro-cに比べて20\%ほど早くなった事が分かる。しかし逆に | |
249 Linux環境では6\%の速度低下が示された。どちらにしてもppcほどの良い結果 | |
250 ではない。これは自由に使えるレジスタが極めて少ないというx86の特殊なア | |
251 ーキテクチャが要因だと考えられる。そのためGCCの最適化が十分に機能でき | |
252 なかった可能性がある。この6\%の差は実用レベルでは問題なく、プログラム | |
253 の構成によっては結果は逆転する事も十分にある。 | |
254 | |
255 ppcにおいてはどのオペレーティングシステムでも、速度最適化を使ったGCCは | |
256 micro-cに比べて早い事が分かる。いずれも約2倍、もしくはそれ以上に速度が | |
257 向上している。これはGCCの最適化機構が十分に働いている要因が大きい。 | |
258 | |
259 \subsubsection{アセンブラ比較} | |
260 実際に出力されたアセンブラから速度向上の要因を確かめるため、quicksort | |
261 プログラムで使用されているコードセグメントを一つ例に挙げる。CbCのプロ | |
262 グラムソースがコード \ref{code:divider-e}である。このコードセグメント | |
263 の速度最適化を使ったGCCによる出力がコード\ref{code:divider-e-gcc}、 | |
264 micro-c による出力がコード \ref{code:divider-e-mc}である。どちらもアー | |
265 キテクチャはppcである。 | |
266 | |
267 \lstinputlisting[ | |
268 caption=quicksortプログラムで使われているコードセグメント, | |
269 label=code:divider-e] | |
270 {sources/divider-e.cbc} | |
271 \begin{minipage}[t]{.45\textwidth} | |
272 \lstinputlisting[ | |
273 caption=divider\_eのGCCによる出力(ppc), | |
274 label=code:divider-e-gcc] | |
275 {sources/divider-e-gcc.asm} | |
276 \end{minipage} | |
277 \hfill | |
278 \begin{minipage}[t]{.45\textwidth} | |
279 \lstinputlisting[ | |
280 caption=divider\_eのmicro-cによる出力(ppc), | |
281 label=code:divider-e-mc] | |
282 {sources/divider-e-mc.asm} | |
283 \end{minipage} | |
284 | |
285 もっとも比較しやすい箇所は\verb|e-1|の処理である。コード | |
286 \ref{code:divider-e-gcc}のGCCではこれを1命令の\verb|addi 5,5,-1| で行 | |
287 っている。 micro-cではこれが\verb|mr, addi, mr|という3命令になっている | |
288 。これは変数\verb|s|の値を一度別のレジスタに移して計算するという処理で | |
289 ある。この様な細かい命令の展開が速度に差が出る要因である。 | |
290 | |
291 またこのppcのアセンブラからも、x86での速度差が少ないことが頷ける。引数 | |
292 のほとんどをメモリに格納するx86では、計算のために一度レジスタに格納し | |
293 ないといけないことから、この命令は結局3命令になるはずであり、実際にx86 | |
294 ではGCC, micro-c共にそのようなコードが出力されていた。 | |
295 | |
296 この結果より、CbCで記述されたプログラムではレジスタが多い方が実効速度 | |
297 の面で有利であるということが分る。これは他のコンパイラ言語でも同じ事が | |
298 言えるが、(手続きやメソッドにおける)前の環境を保持する必要がないCbC | |
299 ではその影響がより強い。 | |
300 | |
301 %レジスタの数は | |
302 | |
303 \subsubsection{ファイルサイズ} | |
304 | |
305 次に、実行ファイルのファイルサイズの面から考察する。 | |
306 | |
307 実行ファイルのファイルサイズは組み込み用途のプログラムには重要な要素と | |
308 なる。多くの場合、組み込み機器では大容量のメモリは用意されておらず、 | |
309 OSも存在しないため仮想記憶の概念がない。そのためメモリに乗り切らないプ | |
310 ログラムはそもそも実行不能である。 | |
311 | |
312 まず、評価の主な特徴として、strip後のファイルサイズ | |
313 \ref{tab:eval-strip} をみると、x86ではmicro-cとGCCでほとんど差がない事 | |
314 が分かる。この環境では速度面でも大きな差はなく、micro-cの精度の良さが | |
315 わかる。 | |
316 | |
317 %デバグ情報のあり/なし/strip後との比較で大きな差が出ているのは全て | |
318 %Linux(PS3含む)である。Linuxでは実行ファイルのファイル形式にELFを用い | |
319 %ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい | |
320 %るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ | |
321 %ているのだと考えられる。 | |
322 %Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された | |
323 %環境ではデバグが困難になることが考えられる。 | |
324 | |
325 また興味深い特徴として、速度最適化とサイズ最適化の差がppc/PS3以外は全 | |
326 くないことも分かった。 サイズ最適化は速度最適化の最適化機能から、ファ | |
327 イルサイズが大きくなるものを除外したものである。評価結果にはサイズ最適 | |
328 化によるファイルサイズの減少はほとんどなく、しかし速度は少々遅くなって | |
329 いる。このことからCbCによるプログラムではサイズ最適化を用いる必要はな | |
330 く、速度最適化で十分であることが分かった。 | |
331 | |
332 | |
333 % ELF, Mach-O | |
334 % o OS Xはデバグ情報が少ない。逆か、ELFが多いのか | |
335 % o x86でほぼ同じサイズ | |
336 % - mcがんばってる | |
337 % o -Osと-O2が変わらない、でも速度は-O2 | |
338 % o PS3とLinuxで大きく違う | |
339 % | |
340 | |
341 \subsubsection{以前のバージョンとの速度比較}\label{sec:compare2old} | |
342 | |
343 古いバージョンとの速度差についても考察を重ねる。 | |
344 実行環境にppcが存在しないのは、\ref{sec:impl-indirect}節における問題の | |
345 ためである。今回用意したプログラムは間接継続を用いているため、古いバー | |
346 ジョンではバグにより実行できなかった。 | |
347 また、速度向上に関する改善は\ref{sec:impl-fastcall}節におけるfastcall | |
348 の追加のみなであり、このfastcallはx86環境にしか影響しないはずである。 | |
349 | |
350 表を見ると、\verb|-O0|の場合は新バージョンの方が旧バージョンより遅くな | |
351 っているのが分かる。これは\ref{sec:impl-parallel}節の一時変数への退避 | |
352 処理のためだと考えられる。この処理では、最適化により無駄なスタックへの | |
353 アクセスは排除されることを期待して実装していた。\verb|-O0|は最適化を行 | |
354 わないので、この場合は逆に遅くなっている。これは予想通りの結果である。 | |
355 しかし最適化を行った場合は新バージョンに劣化はない。したがって一時変数 | |
356 への退避処理においては、期待通り無駄な命令は十分に排除されていることが | |
357 分かった。 | |
358 | |
359 また、それだけなら速度はほぼ同じ結果がでるところだが、ここではいずれの | |
360 環境でも新しいバージョンの方が速い。15--20\%ほど高速化していることがわ | |
361 かる。これは本研究で行った改善の一つ、fastcallの影響である。 | |
362 | |
363 | |
364 | |
365 | |
366 | |
367 | |
368 | |
369 \section{メンテナンス性の向上に関する取り組み}\label{sec:mentainance} | |
370 | |
371 本研究室ではこれまでCbCコンパイラとしてmicro-cを利用していた。このコン | |
372 パイラはベースとなるmicro-cには依存せずに、ほぼ独立な開発を続けている。 | |
373 | |
374 これに対しGCCは現在も精力的に開発が続けられており、年数回のアップデー | |
375 トではバグの除去や最適化の改善などが行われている。 | |
376 そのためCbCコンパイラでもそのリリースに沿ってアップデートすることが望 | |
377 ましく、実際に今回の改善の際にも2010年1月現在での最新リリースである | |
378 4.4.2をベースとして行い、本稿執筆中に4.4.3へのアップデートが行われた。 | |
379 | |
380 しかしアップデートの度に新しいソースコードを書き換えるのは無理があり、 | |
381 現実的ではない。最良の方法はGCCの正式な機能として開発リポジトリにマー | |
382 ジしてもらうことだが、現段階ではそこには至っていない。 | |
383 | |
384 そのため現在はMercurialを使ったソースコード管理を行っている。ここでは | |
385 その手法を説明する。 | |
386 | |
387 \subsection{二つのリポジトリ} | |
388 Mercurialは分散型のバージョン管理システムである。 | |
389 開発環境毎に複数のリポジトリを分散して持つすることができ、そのためそれ | |
390 ぞれのリポジトリのマージの機能に優れる。 | |
391 | |
392 CbCコンパイラの管理ではこの特徴を利用する。 | |
393 具体的にはCbC開発用に二つのリポジトリを持つ。一つは本家のGCCリリースと | |
394 まったく同一のソースをもったGCC-copyと言うリポジトリである。もう一つは | |
395 この GCC-copyからブランチする形で作成したCbConGCCというリポジトリであ | |
396 る。 | |
397 こちらがCbCに関するメインの開発環境となる。図\ref{fig:gcc-repository} | |
398 では中央と右のラインがそのリポジトリを表している。 | |
399 | |
400 \begin{figure}[htpb] | |
401 \begin{center} | |
402 \includegraphics[width=.7\textwidth]{figures/gcc-repository.eps} | |
403 \end{center} | |
404 \caption{CbCコンパイラ開発でのリポジトリ管理(左が本家のリリースタイ | |
405 ムライン、中央がGCC-copy、右がCbCの開発用リポジトリのタイムライン)} | |
406 \label{fig:gcc-repository} | |
407 \end{figure} | |
408 | |
409 新しいバージョンがリリースされた際のCbConGCCでのアップデートは次の手順 | |
410 で実現できる。 | |
411 \begin{itemize} | |
412 \item GCC-copyリポジトリにて | |
413 \begin{enumerate} | |
414 \item GCC-copyリポジトリ中のファイル全てを消す(バージョン管理情 | |
415 報以外) | |
416 \item gcc-core-{\tt\it version}.tar.gzを展開し、全ファイルをGCC-copyに追加 | |
417 \item \verb|hg status|で追加ファイル、削除ファイルを確認 | |
418 \item コミット | |
419 \item gcc-{\tt\it version}タグの追加 | |
420 \end{enumerate} | |
421 \item CbConGCCリポジトリにて | |
422 \begin{enumerate} | |
423 \item GCC-copyから\verb|pull|. | |
424 \item \verb|hg merge|でマージ実行 | |
425 \item 衝突のあったファイルを修正 | |
426 \item 実際にビルドしてテストファイルが動くことを確認 | |
427 \item コミット | |
428 \item cbc-{\tt\it version}タグの追加 | |
429 \end{enumerate} | |
430 \end{itemize} | |
431 | |
432 以上でアップデートが完了する。 | |
433 | |
434 \subsection{このリポジトリ管理方法の評価} | |
435 | |
436 実際にこのリポジトリ管理方法を用いてアップデートを行った。この評価では | |
437 バージョン 4.4.0から4.4.2へのアップデートと、4.4.2から4.4.3へのアップ | |
438 デートを行った。 | |
439 | |
440 アップデートの際に何らかの問題が生じるのはCbConGCCリポジトリでの衝突フ | |
441 ァイルの修正だけである。4.4.3へのアップデートでは特になにも衝突するこ | |
442 とはなかったが、4.4.2ではある関数の引数が変わっており、その修正に手作 | |
443 業を要した。しかし複雑な作業はこの衝突ファイルの修正だけに抑えられる。 | |
444 | |
445 この手法を用いず、これまでの様に一つのリポジトリのみで行っていた場合に | |
446 は、本家GCCの新旧の差分をとるか、もしくは本家の旧GCCとCbCでの差分をと | |
447 り、新しく適用する必要がある。この差分の取得はdiffを使って手動で行う必 | |
448 要があるが手順は非常に複雑になり、どこに問題が生じたかも判別しにくくな | |
449 る。 | |
450 | |
451 新しいリポジトリ管理方法ではdiffを用いた複雑な作業は必要なく、作業は衝 | |
452 突したファイルのみに抑えられる。これによりソースコードアップデートに関 | |
453 するメンテナンス性の向上が実現できた。 | |
454 | |
455 | |
456 | |
457 |