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