|
2
|
1 \chapter{評価・考察}
|
|
0
|
2 \label{chp:eval}
|
|
|
3
|
|
|
4 本章では本研究の評価を行う。
|
|
|
5 まず、gccでのCbCコンパイルにおける利点と欠点を考察する。
|
|
|
6 次にgccベースのCbCコンパイラの性能評価を行う。
|
|
|
7 最後に、\ref{chp:task}章のTaskManagerの開発を元に、CbC言語そのものの記述性、プログラミング手法などについて考察する。
|
|
|
8
|
|
|
9
|
|
2
|
10 \section{gccを使うことの利点・欠点}
|
|
0
|
11 \label{sec:merit}
|
|
|
12
|
|
2
|
13 これまでCbCのコンパイルに使用してきたmc(micro-c)に対し、新しくgccが
|
|
|
14 CwCのフルセットとして使用可能となった。ここでgccを用いることの利点と欠
|
|
|
15 点について考察する。
|
|
0
|
16
|
|
|
17 \subsection*{アーキテクチャ}
|
|
|
18
|
|
|
19 mcにおいてはPPC,x86,MIPS,ARM,SPUなど、多数のCPUアーキテクチャをサポー
|
|
|
20 トしてきた。しかしあるCPUに新しく対応するには多大な時間、労力が必要と
|
|
|
21 なる。
|
|
|
22 gccは現在、既に20を越えるCPUに対応しており、またOS毎のABIの差異も吸収
|
|
|
23 可能である。これはgccをコンパイラとすることに最大の利点である。
|
|
|
24
|
|
|
25 またそれだけでなく、gccは新しいアーキテクチャへの対応も早い。この特徴
|
|
|
26 は、gccがフロントエンドとバックエンドという形で言語実装とアーキテクチ
|
|
|
27 ャを分離していることからくる。一般的に新しいCPUアーキテクチャが開発さ
|
|
|
28 れた場合にはその開発者自身がgccにコミットすることが多いため、組み込み
|
|
|
29 用途を目的の一つとするCbCではよりその強みがます。
|
|
|
30
|
|
|
31 \subsection*{最適化の恩恵}
|
|
|
32 gccは豊富な最適化機構を備えている。
|
|
|
33 代表的な最適化だけでもループ最適化、分岐スレッディング(jump threading)
|
|
|
34 、共通式除去(common subexpression elimination)、命令スケジューリング
|
|
|
35 (instruction scheduling)などがある。
|
|
|
36
|
|
|
37 とくに、プログラムにおいては類似した形の式(expression)を扱うことがよく
|
|
|
38 あるため、共通式除去は非常に効果が高い。同様の効果は同じ式を保持する変
|
|
|
39 数を用意することでも実現できるがソースコードの修正が必要になる。
|
|
|
40 mcにはこの最適化は含まれていないため、複雑な計算式を含むプログラムにお
|
|
|
41 いてはgccの方が良いコンパイル結果を示すものと考えられる。
|
|
|
42
|
|
|
43 %\ref{sec:}の性能評価では最適化の効果についても測定する。
|
|
|
44
|
|
|
45 \subsection*{デバッガ}
|
|
|
46 これまでCbCにはデバッガが存在しなかった。デバッガの実装には出力するア
|
|
|
47 センブラに行番号や変数名、関数名などの情報を付加する必要があるが、gcc
|
|
|
48 は標準でこれを行っている。そのためCのデバッガとして広く一般的に使われ
|
|
|
49 ている gdbをそのままCbCのデバッガとして使用することが可能であり、ソフ
|
|
|
50 トウェア開発の大きな助力となる。
|
|
|
51
|
|
|
52 %ただし継続制御では``next''コマンドが使いづらいなどの操作性の問題がいく
|
|
|
53 %つか確認している。これらは
|
|
|
54
|
|
|
55 %
|
|
|
56 \subsection*{関数呼出しの名残り}
|
|
|
57 上記の利点に対し、gccであるゆえの欠点も存在する。
|
|
|
58
|
|
|
59 本研究による軽量継続制御の実装には\ref{chp:impl}章で説明したように関数
|
|
|
60 の末尾最適化を利用した。それゆえコードセグメントのアセンブラ出力の命令
|
|
|
61 列には一部関数呼び出し時のスタック処理が残ってしまうことが分かっている。
|
|
|
62 特にレジスタの少ないアーキテクチャ、x86などではそれが顕著に現れる。
|
|
|
63
|
|
|
64 mcではコードセグメントと関数は完全に別物として取り扱っており、この様な
|
|
|
65 スタック操作はコードセグメントには現れないため、このオーバヘッドがgcc
|
|
|
66 では不利な点である。
|
|
|
67
|
|
2
|
68 % TODO: 取り除くには…
|
|
|
69
|
|
0
|
70 % スタック処理が残ってしまう
|
|
|
71 % 同じくcpuに特化したコンパイルに比べると
|
|
|
72
|
|
|
73
|
|
|
74 \subsection*{互換性、ABI}
|
|
|
75 %これは最後の考察に入れよう
|
|
|
76 ソースコードレベルでの互換性の問題がある。
|
|
|
77 また、継続制御のパラメタを
|
|
|
78 % 関数宣言
|
|
|
79 % 型推定
|
|
|
80 % ABI、特にppc
|
|
|
81
|
|
|
82
|
|
|
83 % 最適化
|
|
|
84 % SPUでのベクトル演算
|
|
|
85 % gdb
|
|
|
86 % architecture
|
|
|
87
|
|
|
88 % 関数呼び出しのオーバヘッド
|
|
|
89 % 互換性,ソースコード、ABI
|
|
|
90
|
|
|
91
|
|
1
|
92
|
|
|
93
|
|
|
94
|
|
0
|
95 \section{性能評価}
|
|
|
96
|
|
2
|
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
|
|
0
|
121 \subsection{評価手法と環境}
|
|
|
122 実行するプログラムとして、クイックソートのテストプログラムを作成した。
|
|
|
123 クイックソートは再帰呼び出しを伴うため、スタック操作が必須となる。その
|
|
2
|
124 ためより様々な状態でコードセグメントへの継続制御が使用されることになり、
|
|
0
|
125 CbCの性能評価に適していると考えられる。クイックソートはCbCに先立ってC
|
|
2
|
126 で実装し、参考文献\cite{bib:kinjo-2005}で紹介する手法を用いてCbCに変換
|
|
|
127 した。このプログラムは付録\ref{apx:quicksort}に添付する。
|
|
0
|
128
|
|
2
|
129 測定環境は両コンパイラが対応しているアーキテクチャ、OSから以下の5つの
|
|
|
130 組み合わせ[CPUアーキテクチャ/OS種別]を選択した。
|
|
0
|
131 \begin{itemize}
|
|
|
132 \item ppc/OS X
|
|
|
133 \item ppc/linux
|
|
|
134 \item ppc/linux on PS3
|
|
|
135 \item x86/OS X
|
|
|
136 \item x86/linux
|
|
|
137 \end{itemize}
|
|
|
138 なお、mcはmips,armにも対応しているが、現在その処理系が用意できなかった
|
|
2
|
139 ので割愛している。また、GCC-4.2.3ベースコンパイラはppcでは実行不能であ
|
|
|
140 ったためx86のみとなる。
|
|
|
141
|
|
|
142 各評価マシンの詳細は付録\ref{sec:}に掲載する。
|
|
0
|
143
|
|
|
144 %gccのコンパイルでは``-O2 -fomit-pointer''の最適化を付加して測定している。
|
|
|
145 % noreturnもON.
|
|
|
146 % x86ではfastcallもON,
|
|
|
147
|
|
|
148 \subsection{評価結果}
|
|
2
|
149 実効速度の測定結果を表\ref{tab:eval-speed}に示す。
|
|
|
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}
|
|
0
|
187 \begin{table}[htpb]
|
|
|
188 \centering
|
|
|
189 \begin{tabular}{|c|c|c|c|} \hline
|
|
|
190 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} }
|
|
2
|
191 & \multicolumn{2}{c|}{GCC} & \multirow{2}{*}{mc} \\ \cline{2-3}
|
|
|
192 & -O2 & -Os & \\ \hline
|
|
|
193 x86/OS X & 9176 & 9176 & 9172 \\ \hline
|
|
|
194 x86/Linux & 5752 & 5752 & 5796 \\ \hline
|
|
|
195 ppc/OS X & 8576 & 8576 & 12664 \\ \hline
|
|
|
196 ppc/Linux & 10068 & 10068 & 9876 \\ \hline
|
|
|
197 ppc/PS3 & 6960 & 6728 & 8636 \\ \hline
|
|
0
|
198 \end{tabular}
|
|
2
|
199 \caption{実行ファイルのファイルサイズ比較 stripped（単位: bytes）}
|
|
|
200 \label{tab:eval-strip}
|
|
0
|
201 \end{table}
|
|
2
|
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
|
|
0
|
220 % ppcのが圧倒的に早い
|
|
|
221 % x86ではあまりさはでない
|
|
|
222 % 最適化が効いている
|
|
2
|
223 % TODO: ファイルサイズの比較
|
|
|
224 % SPUに送るのに有利
|
|
|
225 % コンパイルにかかる時間？
|
|
0
|
226
|
|
2
|
227 \subsection{評価結果考察}
|
|
|
228 % stripするとx86はサイズに変化がない
|
|
|
229 \subsubsection{速度面}
|
|
|
230 まずは速度面からこの測定結果を考察する。
|
|
|
231
|
|
|
232 まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し
|
|
|
233 ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、
|
|
|
234 ppcでは5〜7倍もの差が生じている。
|
|
|
235 ただしppcのこの以上な速度差は\ref{ssec:}並列代入で示した様に、継続の引
|
|
|
236 数を全て一時変数に入れていることが大きい。その場合最適化なしではすべて
|
|
|
237 の引数を一度メモリに確保するので、その分逆に遅くなっているのだと考えら
|
|
|
238 れる。しかしながら最適化を有効にすることでそのメモリへの一時変数の確保
|
|
|
239 も解消されるということが分かった。
|
|
|
240
|
|
|
241 x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmcを比べると、
|
|
|
242 OS Xではmcに比べて20\%ほど早くなった事が分かる。しかし逆にLinux環境で
|
|
|
243 は6\%の速度低下が示された。どちらにしてもppcほどの良い結果ではない。こ
|
|
|
244 れは自由に使えるレジスタが極めて少ないというx86の特殊なアーキテクチャ
|
|
|
245 が要因だと考えられる。そのためGCCの最適化が十分に機能できなかった可能
|
|
|
246 性がある。この6\%の差は実用レベルでは問題なく、プログラムの構成によっ
|
|
|
247 ては結果は逆転する事も十分にある。
|
|
0
|
248
|
|
2
|
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である。
|
|
0
|
260
|
|
2
|
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 %適化機構が十分に働いている要因が大きい。
|
|
0
|
279
|
|
|
280 %\subsubsection{アセンブラ比較}
|
|
2
|
281 %比較のため、quicksortプログラムで使われているコードセグメントを一つ例
|
|
|
282 %にあげる。 CbCのソースがコード\ref{code:divider_s}、そのコードセグメン
|
|
|
283 %トのgccによる出力がコード\ref{code:divider_s_gcc}、mcによる出力がコー
|
|
|
284 %ド \ref{code:divider_s_mc} である。
|
|
|
285 %
|
|
0
|
286 \lstinputlisting[
|
|
|
287 caption=quicksortプログラムで使われているコードセグメント,
|
|
2
|
288 label=code:divider-e]
|
|
|
289 {sources/divider-e.cbc}
|
|
0
|
290 \begin{minipage}[t]{.45\textwidth}
|
|
|
291 \lstinputlisting[
|
|
2
|
292 caption=divider\_eのgccによる出力(ppc),
|
|
|
293 label=code:divider-e-gcc]
|
|
|
294 {sources/divider-e-gcc.asm}
|
|
0
|
295 \end{minipage}
|
|
|
296 \hfill
|
|
|
297 \begin{minipage}[t]{.45\textwidth}
|
|
|
298 \lstinputlisting[
|
|
2
|
299 caption=divider\_eのmcによる出力(ppc),
|
|
|
300 label=code:divider-e-mc]
|
|
|
301 {sources/divider-e-mc.asm}
|
|
0
|
302 \end{minipage}
|
|
|
303
|
|
2
|
304 もっとも比較しやすい箇所は\verb|e-1|の処理である。
|
|
|
305 コード\ref{code:divider-e-gcc}のgccではこれを1命令の\verb|addi 5,5,-1|
|
|
0
|
306 で行っている。 mcではこれが\verb|mr, addi, mr|という3命令になっている
|
|
|
307 。これは変数\verb|s|の値を一度別のレジスタに移して計算するという処理で
|
|
|
308 ある。この様な細かい命令の展開が速度に差が出る要因である。
|
|
|
309
|
|
2
|
310 またこのppcのアセンブラからも、x86での速度差が少ないことが頷ける。引数
|
|
|
311 のほとんどをメモリに格納するx86では、計算のために一度レジスタに格納し
|
|
|
312 ないといけないことから、この命令は結局3命令になるはずであり、実際にx86
|
|
|
313 ではGCC,mc共にそのようなコードが出力されていた。
|
|
0
|
314
|
|
|
315 この結果より、CbCで記述されたプログラムではレジスタが多い方が実効速度
|
|
|
316 の面で有利であるということが分る。これは他のコンパイラ言語でも同じ事が
|
|
2
|
317 言えるが、（手続きやメソッドにおける）前の環境を保持する必要がないCbC
|
|
|
318 ではその影響がより強い。
|
|
0
|
319
|
|
|
320 %レジスタの数は
|
|
|
321
|
|
2
|
322 \subsubsection{ファイルサイズ}
|
|
|
323
|
|
|
324 次に、実行ファイルのファイルサイズの面から考察する。
|
|
|
325
|
|
|
326 実行ファイルのファイルサイズは組み込み用途のプログラムには重要な要素と
|
|
|
327 なる。多くの場合、組み込み機器では大容量のメモリは用意されておらず、
|
|
|
328 OSも存在しないため仮想記憶の概念がない。そのためメモリに乗り切らないプ
|
|
|
329 ログラムはそもそも実行不能である。
|
|
|
330
|
|
|
331 まず、評価の主な特徴として、strip後のファイルサイズ\ref{tab:eval-strip}
|
|
|
332 をみると、x86ではmcとGCCでほとんど差がない事が分かる。この環境では速度
|
|
|
333 面でも大きな差はなく、mcの精度の良さがわかる。
|
|
|
334
|
|
|
335 デバグ情報のあり／なし／strip後との比較で大きな差が出ているのは全て
|
|
|
336 Linux（PS3含む）である。Linuxでは実行ファイルのファイル形式にELFを用い
|
|
|
337 ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい
|
|
|
338 るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ
|
|
|
339 ているのだと考えられる。
|
|
|
340 Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された
|
|
|
341 環境ではデバグが困難になることが考えられる。
|
|
|
342
|
|
|
343 また興味深い特徴として、-O2と-Osの差がppc/PS3以外は全くないことも分か
|
|
|
344 った。 -Osは-O2の最適化機能から、ファイルサイズが大きくなるものを除外
|
|
|
345 したものである。評価結果には-Osによるファイルサイズの減少はほとんどな
|
|
|
346 く、しかし速度は少々遅くなっている。このことからCbCによるプログラムで
|
|
|
347 は-Osを用いる必要はなく、-O2で十分であることが分かった。
|
|
0
|
348
|
|
|
349
|
|
2
|
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}
|
|
0
|
359
|
|
2
|
360 古いバージョンとの速度差についても考察を重ねる。
|
|
|
361 実行環境にppcが存在しないのは、\ref{sec:impl-indirect}節における問題の
|
|
|
362 ためである。今回用意したプログラムは間接継続を用いているため、古いバー
|
|
|
363 ジョンではバグにより実行できなかった。
|
|
|
364 また、速度向上に関する改善は\ref{sec:impl-fastcall}節におけるfastcall
|
|
|
365 の追加のみなであり、このfastcallはx86環境にしか影響しないはずである。
|
|
0
|
366
|
|
2
|
367 表を見ると、\verb|-O0|の場合は新バージョンの方が旧バージョンより遅くな
|
|
|
368 っているのが分かる。これは\ref{sec:impl-parallel}節の一時変数への退避
|
|
|
369 処理のためだと考えられる。この処理では、最適化により無駄なスタックへの
|
|
|
370 アクセスは排除されることを期待して実装していた。\verb|-O0|は最適化を行
|
|
|
371 わないので、この場合は逆に遅くなっている。これは予想通りの結果である。
|
|
|
372 しかし最適化を行った場合は新バージョンに劣化はない。したがって一時変数
|
|
|
373 への退避処理においては、期待通り無駄な命令は十分に排除されていることが
|
|
|
374 分かった。
|
|
|
375
|
|
|
376 また、それだけなら速度はほぼ同じ結果がでるところだが、ここではいずれの
|
|
|
377 環境でも新しいバージョンの方が速い。15~20\%ほど高速化していることがわ
|
|
|
378 かる。これは本研究で行った改善の一つ、fastcallの影響である。
|
|
0
|
379
|
|
|
380
|
|
|
381
|
|
|
382
|
|
|
383
|
|
2
|
384
|
|
|
385 \section{CbCでのプログラミング}
|
|
|
386
|
|
|
387 % TODO:
|
|
|
388
|
|
|
389
|
|
|
390 \section{バージョン管理}
|
|
|
391
|
|
|
392 % TODO: version management
|
|
|
393
|
|
|
394
|
|
1
|
395
|
|
|
396
|
|
2
|
397 \section{本研究における成果}
|
|
|
398 本研究では、これまでバグが多くプログラムの動作に問題のあった GCCベース
|
|
|
399 のCbCコンパイラを、実用的なプログラムが動くレベルまで改善することがで
|
|
|
400 きた。
|
|
|
401
|
|
|
402 2008年の研究にて、GCCベースのCbCコンパイラは一部実装されていた。
|
|
|
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
|
