Mercurial > hg > Papers > 2010 > kent-master
comparison evaluations.tex @ 2:50e23a4b2f40
add many files.
author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 05 Feb 2010 10:00:05 +0900 |
parents | aa09c34b90d3 |
children | 30c102343b37 |
comparison
equal
deleted
inserted
replaced
1:aa09c34b90d3 | 2:50e23a4b2f40 |
---|---|
1 \chapter{評価} | 1 \chapter{評価・考察} |
2 \label{chp:eval} | 2 \label{chp:eval} |
3 | 3 |
4 本章では本研究の評価を行う。 | 4 本章では本研究の評価を行う。 |
5 まず、gccでのCbCコンパイルにおける利点と欠点を考察する。 | 5 まず、gccでのCbCコンパイルにおける利点と欠点を考察する。 |
6 次にgccベースのCbCコンパイラの性能評価を行う。 | 6 次にgccベースのCbCコンパイラの性能評価を行う。 |
7 最後に、\ref{chp:task}章のTaskManagerの開発を元に、CbC言語そのものの記述性、プログラミング手法などについて考察する。 | 7 最後に、\ref{chp:task}章のTaskManagerの開発を元に、CbC言語そのものの記述性、プログラミング手法などについて考察する。 |
8 | 8 |
9 | 9 |
10 | 10 \section{gccを使うことの利点・欠点} |
11 \section{gccでを使うことの利点・欠点} | |
12 \label{sec:merit} | 11 \label{sec:merit} |
13 | 12 |
14 これまでCbCのコンパイルに使用してきたmc(micro-c)に対し、新しくgccが使 | 13 これまでCbCのコンパイルに使用してきたmc(micro-c)に対し、新しくgccが |
15 用可能となった。ここでgccを用いることの利点と欠点について考察する。 | 14 CwCのフルセットとして使用可能となった。ここでgccを用いることの利点と欠 |
15 点について考察する。 | |
16 | 16 |
17 \subsection*{アーキテクチャ} | 17 \subsection*{アーキテクチャ} |
18 | 18 |
19 mcにおいてはPPC,x86,MIPS,ARM,SPUなど、多数のCPUアーキテクチャをサポー | 19 mcにおいてはPPC,x86,MIPS,ARM,SPUなど、多数のCPUアーキテクチャをサポー |
20 トしてきた。しかしあるCPUに新しく対応するには多大な時間、労力が必要と | 20 トしてきた。しかしあるCPUに新しく対応するには多大な時間、労力が必要と |
62 特にレジスタの少ないアーキテクチャ、x86などではそれが顕著に現れる。 | 62 特にレジスタの少ないアーキテクチャ、x86などではそれが顕著に現れる。 |
63 | 63 |
64 mcではコードセグメントと関数は完全に別物として取り扱っており、この様な | 64 mcではコードセグメントと関数は完全に別物として取り扱っており、この様な |
65 スタック操作はコードセグメントには現れないため、このオーバヘッドがgcc | 65 スタック操作はコードセグメントには現れないため、このオーバヘッドがgcc |
66 では不利な点である。 | 66 では不利な点である。 |
67 | |
68 % TODO: 取り除くには… | |
67 | 69 |
68 % スタック処理が残ってしまう | 70 % スタック処理が残ってしまう |
69 % 同じくcpuに特化したコンパイルに比べると | 71 % 同じくcpuに特化したコンパイルに比べると |
70 | 72 |
71 | 73 |
90 | 92 |
91 | 93 |
92 | 94 |
93 \section{性能評価} | 95 \section{性能評価} |
94 | 96 |
97 \subsection{評価項目、比較対象} | |
98 コンパイラの出力した実行ファイルを複数回実行し、その実効速度を測定する | |
99 。CbCは実用的なプログラムの記述を目的としているので、プログラムの動作 | |
100 速度は性能の評価として妥当だと考えられる。 | |
101 | |
102 またもう一つの項目として、出力した実行ファイルのファイルサイズも評価す | |
103 る。一般的なプログラムではファイルサイズを気にすることは少ないが、CbC | |
104 の用途には組み込みなども考えられているため、ファイルサイズの影響は大き | |
105 い。比較する際はstripコマンドを用いてデバグ情報等を取り除いている。 | |
106 %SPUはm.. | |
107 | |
108 実効速度、ファイルサイズの比較対象として2つ用意した。 | |
109 一つは過去の研究でのGCCベースコンパイラ、つまり今回の改善を含めてない | |
110 ものである。こちらはGCCのバージョン4.2.3をベースとしている。 | |
111 | |
112 もう一つの比較対象にはmicro-cベースのコンパイラ(以下mc)を用いる。 | |
113 さらにGCCでは最適化による効果も評価するため、 | |
114 \begin{inparaenum}[\itshape 1)\ttfamily] | |
115 \item 最適化なし ``-O0'' | |
116 \item 速度最適化 ``-O2 -fomit-framepointer'' | |
117 \item サイズ最適化 ``-Os'' | |
118 \end{inparaenum} | |
119 についてもそれぞれ比較する。 | |
120 | |
95 \subsection{評価手法と環境} | 121 \subsection{評価手法と環境} |
96 性能評価として、実際にコンパイラの出力した実行ファイルを複数回実行し、 | |
97 その実効速度の平均を測定する。 CbCは実用的なプログラムの記述を目的とし | |
98 ているので、プログラムの動作速度は性能評価として妥当だと考えられる。ま | |
99 た速度比較の対象として、もう一つのCbCコンパイラ実装であるmicro-cベース | |
100 のコンパイラ(以下mc)を用いる。 | |
101 | |
102 実行するプログラムとして、クイックソートのテストプログラムを作成した。 | 122 実行するプログラムとして、クイックソートのテストプログラムを作成した。 |
103 クイックソートは再帰呼び出しを伴うため、スタック操作が必須となる。その | 123 クイックソートは再帰呼び出しを伴うため、スタック操作が必須となる。その |
104 ためより多く様々なコードセグメントへの継続制御が使用されることになり、 | 124 ためより様々な状態でコードセグメントへの継続制御が使用されることになり、 |
105 CbCの性能評価に適していると考えられる。クイックソートはCbCに先立ってC | 125 CbCの性能評価に適していると考えられる。クイックソートはCbCに先立ってC |
106 で実装し、参考文献\cite{bib:kinjo}で紹介する手法を用いてCbCに変換した。 | 126 で実装し、参考文献\cite{bib:kinjo-2005}で紹介する手法を用いてCbCに変換 |
107 | 127 した。このプログラムは付録\ref{apx:quicksort}に添付する。 |
108 測定環境は両コンパイラが対応しているアーキテクチャ、OSから以下の5つ | 128 |
109 の組み合わせ[CPUアーキテクチャ/OS種別]を選択した。 | 129 測定環境は両コンパイラが対応しているアーキテクチャ、OSから以下の5つの |
130 組み合わせ[CPUアーキテクチャ/OS種別]を選択した。 | |
110 \begin{itemize} | 131 \begin{itemize} |
111 \item ppc/OS X | 132 \item ppc/OS X |
112 \item ppc/linux | 133 \item ppc/linux |
113 \item ppc/linux on PS3 | 134 \item ppc/linux on PS3 |
114 \item x86/OS X | 135 \item x86/OS X |
115 \item x86/linux | 136 \item x86/linux |
116 \end{itemize} | 137 \end{itemize} |
117 なお、mcはmips,armにも対応しているが、現在その処理系が用意できなかった | 138 なお、mcはmips,armにも対応しているが、現在その処理系が用意できなかった |
118 ので割愛した。 | 139 ので割愛している。また、GCC-4.2.3ベースコンパイラはppcでは実行不能であ |
140 ったためx86のみとなる。 | |
141 | |
142 各評価マシンの詳細は付録\ref{sec:}に掲載する。 | |
119 | 143 |
120 %gccのコンパイルでは``-O2 -fomit-pointer''の最適化を付加して測定している。 | 144 %gccのコンパイルでは``-O2 -fomit-pointer''の最適化を付加して測定している。 |
121 % noreturnもON. | 145 % noreturnもON. |
122 % x86ではfastcallもON, | 146 % x86ではfastcallもON, |
123 | 147 |
124 \subsection{評価結果} | 148 \subsection{評価結果} |
125 実効速度の測定結果を表\ref{tab:eval}に示す。 | 149 実効速度の測定結果を表\ref{tab:eval-speed}に示す。 |
126 ただし環境毎にCPUの速度は異なるので、上下の比較には意味はない。 | 150 ただし環境毎にCPU速度は異なるので、上下の比較には意味はない。 |
151 % -O2で約10秒になる要素数を選んだ方がいいかもしれない | |
152 \begin{table}[htpb] | |
153 \centering | |
154 \begin{tabular}{|c|c|c|c|c|} \hline | |
155 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | |
156 & \multicolumn{3}{c|}{gcc} & \multirow{2}{*}{mc} \\ \cline{2-4} | |
157 &最適化なし&速度最適化&サイズ最適化& \\ \hline | |
158 x86/OS X & 5.901 & 2.434 & 2.785 & 2.857 \\ \hline | |
159 x86/Linux & 5.732 & 2.401 & 2.876 & 2.254 \\ \hline | |
160 ppc/OS X &14.875 & 2.146 & 2.170 & 4.811 \\ \hline | |
161 ppc/Linux &19.793 & 3.955 & 4.013 & 6.454 \\ \hline | |
162 ppc/PS3 &39.176 & 5.874 & 6.111 &11.121 \\ \hline | |
163 \end{tabular} | |
164 \caption{アーキテクチャ毎のgccとmcの速度比較(単位: 秒)} | |
165 \label{tab:eval-speed} | |
166 \end{table} | |
167 | |
168 次に実行ファイルのstrip前のファイルサイズを表\ref{tab:eval-nostrip} | |
169 に、strip後のファイルサイズを表\ref{tab:eval-strip}に示す。 | |
170 | |
171 \begin{table}[htpb] | |
172 \centering | |
173 \begin{tabular}{|c|c|c|c|c|c|} \hline | |
174 \multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | |
175 & \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{mc} \\ \cline{2-5} | |
176 & \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} & \\ \cline{2-5} | |
177 & -O2 & -Os & -O2 & -Os & \\ \hline | |
178 x86/OS X & 11100 & 11100 & 9804 & 9804 & 11136 \\ \hline | |
179 x86/Linux & 18444 & 17310 & 8216 & 8214 & 9844 \\ \hline | |
180 ppc/OS X & 10392 & 10392 & 9172 & 9172 & 14396 \\ \hline | |
181 ppc/Linux & 25138 & 23876 & 13030 & 13028 & 15453 \\ \hline | |
182 ppc/PS3 & 22142 & 20452 & 9906 & 9672 & 15463 \\ \hline | |
183 \end{tabular} | |
184 \caption{実行ファイルのファイルサイズ比較 not stripped(単位: bytes)} | |
185 \label{tab:eval-nostrip} | |
186 \end{table} | |
127 \begin{table}[htpb] | 187 \begin{table}[htpb] |
128 \centering | 188 \centering |
129 \begin{tabular}{|c|c|c|c|} \hline | 189 \begin{tabular}{|c|c|c|c|} \hline |
130 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | 190 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } |
131 & \multicolumn{2}{c|}{gcc} & \multirow{2}{*}{mc} \\ \cline{2-3} | 191 & \multicolumn{2}{c|}{GCC} & \multirow{2}{*}{mc} \\ \cline{2-3} |
132 & 最適化なし & 最適化あり & \\ \hline | 192 & -O2 & -Os & \\ \hline |
133 x86/OS X & 5.901 & 2.213 & 2.857 \\ \hline | 193 x86/OS X & 9176 & 9176 & 9172 \\ \hline |
134 x86/Linux & 5.869 & 2.401 & 2.254 \\ \hline | 194 x86/Linux & 5752 & 5752 & 5796 \\ \hline |
135 ppc/OS X &14.875 & 2.146 & 4.811 \\ \hline | 195 ppc/OS X & 8576 & 8576 & 12664 \\ \hline |
136 ppc/Linux &19.722 & 3.927 & 6.596 \\ \hline | 196 ppc/Linux & 10068 & 10068 & 9876 \\ \hline |
137 ppc/PS3 &26.169 & 6.104 &11.536 \\ \hline | 197 ppc/PS3 & 6960 & 6728 & 8636 \\ \hline |
138 \end{tabular} | 198 \end{tabular} |
139 \caption{アーキテクチャ毎のgccとmcの速度比較(単位: 秒)} | 199 \caption{実行ファイルのファイルサイズ比較 stripped(単位: bytes)} |
140 \label{tab:eval} | 200 \label{tab:eval-strip} |
141 \end{table} | 201 \end{table} |
202 | |
203 最後に、本研究での実装GCC-4.4.2と以前のバージョンGCC-4.2.3との比較であ | |
204 る。こちらはx86のみ、最適化も-Osは対応していない。 | |
205 \begin{table}[htpb] | |
206 \centering | |
207 \begin{tabular}{|c|c|c|c|c|} \hline | |
208 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } | |
209 & \multicolumn{2}{c|}{CbC on GCC-4.4.2} & | |
210 \multicolumn{2}{c|}{CbC on GCC-4.2.3} \\ \hline | |
211 & -O0 & -O2 & -O0 & -O2 \\ \hline | |
212 x86/OS X & 5.907 & 2.434 & 4.668 & 3.048 \\ \hline | |
213 x86/Linux & 5.715 & 2.401 & 4.525 & 2.851 \\ \hline | |
214 \end{tabular} | |
215 \caption{GCC-4.2.3ベースとGCC-4.4.2ベースの速度比較(単位: 秒)} | |
216 \label{tab:eval-speed} | |
217 \end{table} | |
218 | |
219 | |
142 % ppcのが圧倒的に早い | 220 % ppcのが圧倒的に早い |
143 % x86ではあまりさはでない | 221 % x86ではあまりさはでない |
144 % 最適化が効いている | 222 % 最適化が効いている |
145 | 223 % TODO: ファイルサイズの比較 |
146 まずどのアーキテクチャにおいてもgccの最適化の効果が大きいことが分かる | 224 % SPUに送るのに有利 |
147 。 x86では約2.5倍、ppcでは4~7倍もの差が生じている。ppcの方で異様に効果 | 225 % コンパイルにかかる時間? |
148 が高いように見えるのは、関数やコードセグメントの引数渡しがレジスタベー | 226 |
149 スのため、最適化なしの場合には無駄なメモリアクセスが生じているためであ | 227 \subsection{評価結果考察} |
150 る。 | 228 % stripするとx86はサイズに変化がない |
151 | 229 \subsubsection{速度面} |
152 x86はOS XとLinuxの環境で測定を行った。OS Xではmcに比べて20\%ほど早くな | 230 まずは速度面からこの測定結果を考察する。 |
153 ったことが分かる。しかし逆にLinux環境では6\%の速度低下が示された。 | 231 |
154 どちらにおいてもppcほどの良い結果ではない。これは自由に使えるレジスタ | 232 まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し |
155 が極めて少ないというx86の特殊なアーキテクチャが要因だと考えられる。そ | 233 ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、 |
156 のためにgccの最適化が十分に働かなかった可能性がある。逆に言うとmcが高 | 234 ppcでは5〜7倍もの差が生じている。 |
157 いレベルでx86のアセンブラ命令を実行しているともとれる。この6\%の差は実 | 235 ただしppcのこの以上な速度差は\ref{ssec:}並列代入で示した様に、継続の引 |
158 用レベルでは問題なく、プログラムの構成によっては結果は逆転する事も十分 | 236 数を全て一時変数に入れていることが大きい。その場合最適化なしではすべて |
159 にある。 | 237 の引数を一度メモリに確保するので、その分逆に遅くなっているのだと考えら |
160 | 238 れる。しかしながら最適化を有効にすることでそのメモリへの一時変数の確保 |
161 ppcではどのオペレーティングシステムでもmcに比べてgccが早いことが分かる | 239 も解消されるということが分かった。 |
162 。いずれも約2倍近くあるいはそれ以上に速度が向上している。これはgccの最 | 240 |
163 適化機構が十分に働いている要因が大きい。 | 241 x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmcを比べると、 |
242 OS Xではmcに比べて20\%ほど早くなった事が分かる。しかし逆にLinux環境で | |
243 は6\%の速度低下が示された。どちらにしてもppcほどの良い結果ではない。こ | |
244 れは自由に使えるレジスタが極めて少ないというx86の特殊なアーキテクチャ | |
245 が要因だと考えられる。そのためGCCの最適化が十分に機能できなかった可能 | |
246 性がある。この6\%の差は実用レベルでは問題なく、プログラムの構成によっ | |
247 ては結果は逆転する事も十分にある。 | |
248 | |
249 ppcにおいてはどのオペレーティングシステムでも、速度最適化を使ったGCCは | |
250 mcに比べて早い事が分かる。いずれも約2倍、もしくはそれ以上に速度が向上 | |
251 している。これはGCCの最適化機構が十分に働いている要因が大きい。 | |
252 | |
253 \subsubsection{アセンブラ比較} | |
254 実際に出力されたアセンブラから速度向上の要因を確かめるため、quicksort | |
255 プログラムで使用されているコードセグメントを一つ例に挙げる。CbCのプロ | |
256 グラムソースがコード \ref{code:divider-e}である。このコードセグメント | |
257 の速度最適化を使ったGCCによる出力がコード\ref{code:divider-e-gcc}、mc | |
258 による出力がコード \ref{code:divider-e-mc}である。 | |
259 どちらもアーキテクチャはppcである。 | |
260 | |
261 %まずどのアーキテクチャにおいてもgccの最適化の効果が大きいことが分かる | |
262 %。 x86では約2.5倍、ppcでは4~7倍もの差が生じている。ppcの方で異様に効果 | |
263 %が高いように見えるのは、関数やコードセグメントの引数渡しがレジスタベー | |
264 %スのため、最適化なしの場合には無駄なメモリアクセスが生じているためであ | |
265 %る。 | |
266 | |
267 %x86はOS XとLinuxの環境で測定を行った。OS Xではmcに比べて20\%ほど早くな | |
268 %ったことが分かる。しかし逆にLinux環境では6\%の速度低下が示された。 | |
269 %どちらにおいてもppcほどの良い結果ではない。これは自由に使えるレジスタ | |
270 %が極めて少ないというx86の特殊なアーキテクチャが要因だと考えられる。そ | |
271 %のためにgccの最適化が十分に働かなかった可能性がある。逆に言うとmcが高 | |
272 %いレベルでx86のアセンブラ命令を実行しているともとれる。この6\%の差は実 | |
273 %用レベルでは問題なく、プログラムの構成によっては結果は逆転する事も十分 | |
274 %にある。 | |
275 | |
276 %ppcではどのオペレーティングシステムでもmcに比べてgccが早いことが分かる | |
277 %。いずれも約2倍近くあるいはそれ以上に速度が向上している。これはgccの最 | |
278 %適化機構が十分に働いている要因が大きい。 | |
164 | 279 |
165 %\subsubsection{アセンブラ比較} | 280 %\subsubsection{アセンブラ比較} |
166 比較のため、quicksortプログラムで使われているコードセグメントを一つ例 | 281 %比較のため、quicksortプログラムで使われているコードセグメントを一つ例 |
167 にあげる。 CbCのソースがコード\ref{code:divider_s}、そのコードセグメン | 282 %にあげる。 CbCのソースがコード\ref{code:divider_s}、そのコードセグメン |
168 トのgccによる出力がコード\ref{code:divider_s_gcc}、mcによる出力がコー | 283 %トのgccによる出力がコード\ref{code:divider_s_gcc}、mcによる出力がコー |
169 ド \ref{code:divider_s_mc} である。 | 284 %ド \ref{code:divider_s_mc} である。 |
170 | 285 % |
171 \lstinputlisting[ | 286 \lstinputlisting[ |
172 caption=quicksortプログラムで使われているコードセグメント, | 287 caption=quicksortプログラムで使われているコードセグメント, |
173 label=code:divider_s] | 288 label=code:divider-e] |
174 {sources/quicksort_divider_s.cbc} | 289 {sources/divider-e.cbc} |
175 \begin{minipage}[t]{.45\textwidth} | 290 \begin{minipage}[t]{.45\textwidth} |
176 \lstinputlisting[ | 291 \lstinputlisting[ |
177 caption=divider\_sのgccによる出力(PowerPC), | 292 caption=divider\_eのgccによる出力(ppc), |
178 label=code:divider_s_gcc] | 293 label=code:divider-e-gcc] |
179 {sources/gcc_divider_s.asm} | 294 {sources/divider-e-gcc.asm} |
180 \end{minipage} | 295 \end{minipage} |
181 \hfill | 296 \hfill |
182 \begin{minipage}[t]{.45\textwidth} | 297 \begin{minipage}[t]{.45\textwidth} |
183 \lstinputlisting[ | 298 \lstinputlisting[ |
184 caption=divider\_sのmcによる出力(PowerPC), | 299 caption=divider\_eのmcによる出力(ppc), |
185 label=code:divider_s_mc] | 300 label=code:divider-e-mc] |
186 {sources/mc_divider_s.asm} | 301 {sources/divider-e-mc.asm} |
187 \end{minipage} | 302 \end{minipage} |
188 | 303 |
189 もっとも比較しやすい箇所は\verb|s+1|の処理である。 | 304 もっとも比較しやすい箇所は\verb|e-1|の処理である。 |
190 コード\ref{code:divider_s_gcc}のgccではこれを1命令の\verb|addi 4,4,1| | 305 コード\ref{code:divider-e-gcc}のgccではこれを1命令の\verb|addi 5,5,-1| |
191 で行っている。 mcではこれが\verb|mr, addi, mr|という3命令になっている | 306 で行っている。 mcではこれが\verb|mr, addi, mr|という3命令になっている |
192 。これは変数\verb|s|の値を一度別のレジスタに移して計算するという処理で | 307 。これは変数\verb|s|の値を一度別のレジスタに移して計算するという処理で |
193 ある。この様な細かい命令の展開が速度に差が出る要因である。 | 308 ある。この様な細かい命令の展開が速度に差が出る要因である。 |
194 | 309 |
195 またこの出力からも、x86での速度差が少ないことが頷ける。引数のほとんど | 310 またこのppcのアセンブラからも、x86での速度差が少ないことが頷ける。引数 |
196 をメモリに格納するx86では計算には一度レジスタに格納しないといけない事 | 311 のほとんどをメモリに格納するx86では、計算のために一度レジスタに格納し |
197 から、結局3 命令になる。そのためgccの最適化が十分には働かないのである。 | 312 ないといけないことから、この命令は結局3命令になるはずであり、実際にx86 |
198 実際x86でのdivider\_sのアセンブラ出力はgccでは 24命令、mcでは18命令と | 313 ではGCC,mc共にそのようなコードが出力されていた。 |
199 となっている。 | |
200 | 314 |
201 この結果より、CbCで記述されたプログラムではレジスタが多い方が実効速度 | 315 この結果より、CbCで記述されたプログラムではレジスタが多い方が実効速度 |
202 の面で有利であるということが分る。これは他のコンパイラ言語でも同じ事が | 316 の面で有利であるということが分る。これは他のコンパイラ言語でも同じ事が |
203 言えるが、前の(手続きやメソッドにおける)環境を保持する必要がないCbCでは | 317 言えるが、(手続きやメソッドにおける)前の環境を保持する必要がないCbC |
204 その影響がより強い。 | 318 ではその影響がより強い。 |
205 | 319 |
206 %レジスタの数は | 320 %レジスタの数は |
207 | 321 |
208 | 322 \subsubsection{ファイルサイズ} |
209 | 323 |
210 %まずどのアーキテクチャにおいても、gccを使った場合は最適化の有無で大きな差が出ていることが分かる。 | 324 次に、実行ファイルのファイルサイズの面から考察する。 |
211 %ppc/OS Xでは倍以上の速度を示すことができた。 | 325 |
212 %これはgccの最適化機構が十分に働いている要因が大きい。 | 326 実行ファイルのファイルサイズは組み込み用途のプログラムには重要な要素と |
213 %特に構造体のポインタからそのメンバにアクセスする処理(Cにおけるアロー演算子である)では違いがでた。ppcではその処理のために | 327 なる。多くの場合、組み込み機器では大容量のメモリは用意されておらず、 |
214 %特に共通部分式除去(Common Subexpression Elimination)の処理はmcにはなく、この例題では多数その処理が適用可能な部分が出てきているためその影響があるものと思われる。 | 328 OSも存在しないため仮想記憶の概念がない。そのためメモリに乗り切らないプ |
215 %x86/OS Xでは約23\%ほど高速化された。 | 329 ログラムはそもそも実行不能である。 |
216 %x86/OS Xでは約23\%、 ppc/OS Xでは最適化ありのgccはmcと比べて倍以上の速度を示すことができた。 | 330 |
217 %しかしx86/Linuxでは逆に6\%ほど速度が低下している事が分かる。 | 331 まず、評価の主な特徴として、strip後のファイルサイズ\ref{tab:eval-strip} |
218 %この主な原因は関数呼出し時のスタック操作である。今回\ref{chp:impl}章で説明したように、継続制御の実装には末尾最適化を応用する形をとった。そのためgccとしては関数として処理しているので、一部のスタック操作(x86なら\verb|pop, push|である)が残ってしまうことが分かっている。元から継続制御用に設計されたmcではそれが存在しないため、その分の処理が速度としてに現れたものと思われる。 | 332 をみると、x86ではmcとGCCでほとんど差がない事が分かる。この環境では速度 |
219 %レジスタの多いアーキテクチャであるほど、速度は改善されると考えられる。 | 333 面でも大きな差はなく、mcの精度の良さがわかる。 |
220 %その中でPowerPC(ppc)での最適化ありとなしの差が非常に大きい。これはppcアセンブラの特徴であるレジスタの多さが原因の一つである。ppcの関数呼出し規約ではほとんどの引数はレジスタにのせて呼出し先に渡すことができる。 | 334 |
221 %しかし呼出し先でさらに別の関数を呼び出す場合はそのレジスタを置き換えるため、スタックに積むなど値を保存しなければならない。この処理を最適に行うには呼び出し後の使用する変数、保持すべき変数を考慮する必要があるため、単純に全てをスタックに積む事とは違う処理が必要になる。 | 335 デバグ情報のあり/なし/strip後との比較で大きな差が出ているのは全て |
222 | 336 Linux(PS3含む)である。Linuxでは実行ファイルのファイル形式にELFを用い |
223 | 337 ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい |
224 \section{CbCでのプログラム} | 338 るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ |
225 | 339 ているのだと考えられる。 |
340 Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された | |
341 環境ではデバグが困難になることが考えられる。 | |
342 | |
343 また興味深い特徴として、-O2と-Osの差がppc/PS3以外は全くないことも分か | |
344 った。 -Osは-O2の最適化機能から、ファイルサイズが大きくなるものを除外 | |
345 したものである。評価結果には-Osによるファイルサイズの減少はほとんどな | |
346 く、しかし速度は少々遅くなっている。このことからCbCによるプログラムで | |
347 は-Osを用いる必要はなく、-O2で十分であることが分かった。 | |
348 | |
349 | |
350 % ELF, Mach-O | |
351 % o OS Xはデバグ情報が少ない。逆か、ELFが多いのか | |
352 % o x86でほぼ同じサイズ | |
353 % - mcがんばってる | |
354 % o -Osと-O2が変わらない、でも速度は-O2 | |
355 % o PS3とLinuxで大きく違う | |
356 % | |
357 | |
358 \subsubsection{以前のバージョンとの速度比較}\label{sec:compare2old} | |
359 | |
360 古いバージョンとの速度差についても考察を重ねる。 | |
361 実行環境にppcが存在しないのは、\ref{sec:impl-indirect}節における問題の | |
362 ためである。今回用意したプログラムは間接継続を用いているため、古いバー | |
363 ジョンではバグにより実行できなかった。 | |
364 また、速度向上に関する改善は\ref{sec:impl-fastcall}節におけるfastcall | |
365 の追加のみなであり、このfastcallはx86環境にしか影響しないはずである。 | |
366 | |
367 表を見ると、\verb|-O0|の場合は新バージョンの方が旧バージョンより遅くな | |
368 っているのが分かる。これは\ref{sec:impl-parallel}節の一時変数への退避 | |
369 処理のためだと考えられる。この処理では、最適化により無駄なスタックへの | |
370 アクセスは排除されることを期待して実装していた。\verb|-O0|は最適化を行 | |
371 わないので、この場合は逆に遅くなっている。これは予想通りの結果である。 | |
372 しかし最適化を行った場合は新バージョンに劣化はない。したがって一時変数 | |
373 への退避処理においては、期待通り無駄な命令は十分に排除されていることが | |
374 分かった。 | |
375 | |
376 また、それだけなら速度はほぼ同じ結果がでるところだが、ここではいずれの | |
377 環境でも新しいバージョンの方が速い。15~20\%ほど高速化していることがわ | |
378 かる。これは本研究で行った改善の一つ、fastcallの影響である。 | |
379 | |
380 | |
381 | |
382 | |
383 | |
384 | |
385 \section{CbCでのプログラミング} | |
386 | |
387 % TODO: | |
388 | |
389 | |
390 \section{バージョン管理} | |
391 | |
392 % TODO: version management | |
226 | 393 |
227 | 394 |
228 | 395 |
229 | 396 |
230 \section{本研究における成果} | 397 \section{本研究における成果} |
231 本研究では、これまでバグが多くプログラムの動作に問題のあった | 398 本研究では、これまでバグが多くプログラムの動作に問題のあった GCCベース |
232 GCCベースのCbCコンパイラを、実用的なプログラムが動くレベルまで改善する | 399 のCbCコンパイラを、実用的なプログラムが動くレベルまで改善することがで |
233 ことができた。 | 400 きた。 |
234 | 401 |
235 | 402 2008年の研究にて、GCCベースのCbCコンパイラは一部実装されていた。 |
236 \section{以前のバージョンとの速度比較} | 403 そして本研究により、そのコンパイラの改善が行われた。 |
404 | |
405 \begin{itemize} | |
406 \item CwCの全機能に対応 | |
407 \item 一部バグのあったアーキテクチャに対応 | |
408 \item バージョン管理の | |
409 \item 宣言の簡略化 | |
410 \item | |
411 \end{itemize} | |
412 | |
413 | |
414 | |
415 | |
416 | |
417 |