comparison evaluations.tex @ 8:4b2af58b0302 probation_version

the version for probation.
author kent <kent@cr.ie.u-ryukyu.ac.jp>
date Tue, 16 Feb 2010 14:04:40 +0900
parents 8ef81ff8cb52
children
comparison
equal deleted inserted replaced
7:8ef81ff8cb52 8:4b2af58b0302
43 43
44 micro-cにおいてはPPC, x86, MIPS, ARM, SPUなど、多数のCPUアーキテクチャ 44 micro-cにおいてはPPC, x86, MIPS, ARM, SPUなど、多数のCPUアーキテクチャ
45 をサポートしてきた。しかし他のCPUに新しく対応するには多大な時間、労力 45 をサポートしてきた。しかし他のCPUに新しく対応するには多大な時間、労力
46 が必要となる。 46 が必要となる。
47 GCCは現在、既に20を越えるCPUに対応しており、またOS毎のABIの差異も吸収 47 GCCは現在、既に20を越えるCPUに対応しており、またOS毎のABIの差異も吸収
48 可能である。これはGCCをコンパイラとすることに最大の利点である。 48 可能である。これはGCCをコンパイラとすることの最大の利点である。
49 49
50 またそれだけでなく、GCCは新しいアーキテクチャへの対応も早い。この特徴 50 またそれだけでなく、GCCは新しいアーキテクチャへの対応も早い。この特徴
51 は、GCCがフロントエンドとバックエンドという形で言語実装とアーキテクチ 51 は、GCCがフロントエンドとバックエンドという形で言語実装とアーキテクチ
52 ャを分離していることからくる。一般的に新しいCPUアーキテクチャが開発さ 52 ャを分離していることからくる。一般的に新しいCPUアーキテクチャが開発さ
53 れた場合にはその開発者自身がGCCにコミットすることが多いため、組み込み 53 れた場合にはその開発者自身がGCCにコミットすることが多いため、組み込み
94 \subsection*{互換性、ABI} 94 \subsection*{互換性、ABI}
95 また、同じく関数呼び出しの名残りから、GCCではmicro-cとのバイナリレベル 95 また、同じく関数呼び出しの名残りから、GCCではmicro-cとのバイナリレベル
96 での互換性がない。つまりGCCでコンパイルしたコードセグメントからmicro-c 96 での互換性がない。つまりGCCでコンパイルしたコードセグメントからmicro-c
97 でコンパイルしたコードセグメントに継続することはできない。 97 でコンパイルしたコードセグメントに継続することはできない。
98 98
99 これはmicro-cでの軽量継続のABIが関数とはまったく違うものだからである。 99 これはmicro-cでの軽量継続のABIが関数とはまったく異なるものだからである
100 今回はtailcallを実装に用いたため、関数としての制限があり、micro-cの 100 。今回はtailcallを実装に用いたため、関数としての制限があり、micro-cの
101 ABIに合わせることはできなかった。 101 ABIに合わせることはできなかった。
102 102
103 この問題はGCCの欠点というわけではないが、CbCベースの共有ライブラリを生 103 この問題はGCCの欠点というわけではないが、CbCベースの共有ライブラリを生
104 成・使用する場合には注意が必要となる。 104 成・使用する場合には注意が必要となる。
105 105
123 一つは過去の研究でのGCCベースコンパイラ、つまり今回の改善を含めてない 123 一つは過去の研究でのGCCベースコンパイラ、つまり今回の改善を含めてない
124 ものである。こちらはGCCのバージョン4.2.3をベースとしている。 124 ものである。こちらはGCCのバージョン4.2.3をベースとしている。
125 125
126 もう一つの比較対象にはmicro-cベースのコンパイラを用いる。 126 もう一つの比較対象にはmicro-cベースのコンパイラを用いる。
127 さらにGCCでは最適化による効果も評価するため、 127 さらにGCCでは最適化による効果も評価するため、
128 \begin{inparaenum}[\itshape 1)\ttfamily] 128 \begin{inparaenum}[\bfseries\itshape 1)\ttfamily]
129 \item 最適化なし ``-O0'' 129 \item 最適化なし ``-O0''
130 \item 速度最適化 ``-O2 -fomit-framepointer'' 130 \item 速度最適化 ``-O2 -fomit-framepointer''
131 \item サイズ最適化 ``-Os'' 131 \item サイズ最適化 ``-Os''
132 \end{inparaenum} 132 \end{inparaenum}
133 についてもそれぞれ比較する。 133 についてもそれぞれ比較する。
178 \end{tabular} 178 \end{tabular}
179 \caption{アーキテクチャ毎のGCCとmicro-cの速度比較(単位: 秒)} 179 \caption{アーキテクチャ毎のGCCとmicro-cの速度比較(単位: 秒)}
180 \label{tab:speed-mc-vs-gcc} 180 \label{tab:speed-mc-vs-gcc}
181 \end{table} 181 \end{table}
182 182
183 実行ファイルのstrip前のファイルサイズを表\ref{tab:eval-nostrip} 183 実行ファイルstrip後のファイルサイズを表\ref{tab:eval-strip}に示す。
184 に、strip後のファイルサイズを表\ref{tab:eval-strip}に示す。 184
185 185 %\begin{table}[htpb]
186 \begin{table}[htpb] 186 %\centering
187 \centering 187 %\begin{tabular}{|c|c|c|c|c|c|} \hline
188 \begin{tabular}{|c|c|c|c|c|c|} \hline 188 %\multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ} }
189 \multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ} } 189 %& \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{micro-c} \\ \cline{2-5}
190 & \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{micro-c} \\ \cline{2-5} 190 %& \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} & \\ \cline{2-5}
191 & \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} & \\ \cline{2-5} 191 %& 速度最適化 & サイズ最適化 & 速度最適化 & サイズ最適化 & \\ \hline
192 & 速度最適化 & サイズ最適化 & 速度最適化 & サイズ最適化 & \\ \hline 192 %x86/OS X & 11100 & 11100 & 9804 & 9804 & 11136 \\ \hline
193 x86/OS X & 11100 & 11100 & 9804 & 9804 & 11136 \\ \hline 193 %x86/Linux & 18444 & 17310 & 8216 & 8214 & 9844 \\ \hline
194 x86/Linux & 18444 & 17310 & 8216 & 8214 & 9844 \\ \hline 194 %ppc/OS X & 10392 & 10392 & 9172 & 9172 & 14396 \\ \hline
195 ppc/OS X & 10392 & 10392 & 9172 & 9172 & 14396 \\ \hline 195 %ppc/Linux & 25138 & 23876 & 13030 & 13028 & 15453 \\ \hline
196 ppc/Linux & 25138 & 23876 & 13030 & 13028 & 15453 \\ \hline 196 %ppc/PS3 & 22142 & 20452 & 9906 & 9672 & 15463 \\ \hline
197 ppc/PS3 & 22142 & 20452 & 9906 & 9672 & 15463 \\ \hline 197 %\end{tabular}
198 \end{tabular} 198 %\caption{実行ファイルのファイルサイズ比較 not stripped(単位: bytes)}
199 \caption{実行ファイルのファイルサイズ比較 not stripped(単位: bytes)} 199 %\label{tab:eval-nostrip}
200 \label{tab:eval-nostrip} 200 %\end{table}
201 \end{table}
202 \begin{table}[htpb] 201 \begin{table}[htpb]
203 \centering 202 \centering
204 \begin{tabular}{|c|c|c|c|} \hline 203 \begin{tabular}{|c|c|c|c|} \hline
205 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } 204 \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} }
206 & \multicolumn{2}{c|}{GCC} & \multirow{2}{*}{micro-c} \\ \cline{2-3} 205 & \multicolumn{2}{c|}{GCC} & \multirow{2}{*}{micro-c} \\ \cline{2-3}
236 \subsection{評価結果考察} 235 \subsection{評価結果考察}
237 % stripするとx86はサイズに変化がない 236 % stripするとx86はサイズに変化がない
238 \subsubsection{速度面} 237 \subsubsection{速度面}
239 まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し 238 まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し
240 ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、 239 ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、
241 ppcでは5〜7倍もの差が生じている。 240 ppcでは5〜7倍もの差が生じている。ただしppcのこの異常な速度差は
242 ただしppcのこの以上な速度差は\ref{sec:impl-parallel}並列代入で示した様に、継続の引 241 \ref{sec:impl-parallel}並列代入で示した様に、継続の引数を全て一時変数
243 数を全て一時変数に入れていることが大きい。その場合最適化なしではすべて 242 に入れていることが大きい。その場合最適化なしではすべての引数を一度メモ
244 の引数を一度メモリに確保するので、その分逆に遅くなっているのだと考えら 243 リに確保するので、その分逆に遅くなっているのだと考えられる。しかしなが
245 れる。しかしながら最適化を有効にすることでそのメモリへの一時変数の確保 244 ら最適化を有効にすることでそのメモリへの一時変数の確保も解消されるとい
246 も解消されるということが分かった。 245 うことが分かった。
247 246
248 x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmicro-cを比べる 247 x86はOS XとLinuxの環境で測定を行った。速度最適化のGCCとmicro-cを比べる
249 と、 OS Xではmicro-cに比べて20\%ほど早くなった事が分かる。しかし逆に 248 と、 OS Xではmicro-cに比べて20\%ほど早くなった事が分かる。しかし逆に
250 Linux環境では6\%の速度低下が示された。どちらにしてもppcほどの良い結果 249 Linux環境では6\%の速度低下が示された。どちらにしてもppcほどの良い結果
251 ではない。これは自由に使えるレジスタが極めて少ないというx86の特殊なア 250 ではない。これは自由に使えるレジスタが極めて少ないというx86の特殊なア
313 まず、評価の主な特徴として、strip後のファイルサイズ 312 まず、評価の主な特徴として、strip後のファイルサイズ
314 \ref{tab:eval-strip} をみると、x86ではmicro-cとGCCでほとんど差がない事 313 \ref{tab:eval-strip} をみると、x86ではmicro-cとGCCでほとんど差がない事
315 が分かる。この環境では速度面でも大きな差はなく、micro-cの精度の良さが 314 が分かる。この環境では速度面でも大きな差はなく、micro-cの精度の良さが
316 わかる。 315 わかる。
317 316
318 デバグ情報のあり/なし/strip後との比較で大きな差が出ているのは全て 317 %デバグ情報のあり/なし/strip後との比較で大きな差が出ているのは全て
319 Linux(PS3含む)である。Linuxでは実行ファイルのファイル形式にELFを用い 318 %Linux(PS3含む)である。Linuxでは実行ファイルのファイル形式にELFを用い
320 ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい 319 %ている。この形式はLinuxの標準的な実行形式で、様々な研究に用いられてい
321 るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ 320 %るため、Mach-Oと比べて付加機能が豊富である。そのため多くの情報が含まれ
322 ているのだと考えられる。 321 %ているのだと考えられる。
323 Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された 322 %Linuxは組み込み用途に多く用いられているため、極端にメモリの制限された
324 環境ではデバグが困難になることが考えられる。 323 %環境ではデバグが困難になることが考えられる。
325 324
326 また興味深い特徴として、速度最適化とサイズ最適化の差がppc/PS3以外は全 325 また興味深い特徴として、速度最適化とサイズ最適化の差がppc/PS3以外は全
327 くないことも分かった。 サイズ最適化は速度最適化の最適化機能から、ファ 326 くないことも分かった。 サイズ最適化は速度最適化の最適化機能から、ファ
328 イルサイズが大きくなるものを除外したものである。評価結果にはサイズ最適 327 イルサイズが大きくなるものを除外したものである。評価結果にはサイズ最適
329 化によるファイルサイズの減少はほとんどなく、しかし速度は少々遅くなって 328 化によるファイルサイズの減少はほとんどなく、しかし速度は少々遅くなって
356 しかし最適化を行った場合は新バージョンに劣化はない。したがって一時変数 355 しかし最適化を行った場合は新バージョンに劣化はない。したがって一時変数
357 への退避処理においては、期待通り無駄な命令は十分に排除されていることが 356 への退避処理においては、期待通り無駄な命令は十分に排除されていることが
358 分かった。 357 分かった。
359 358
360 また、それだけなら速度はほぼ同じ結果がでるところだが、ここではいずれの 359 また、それだけなら速度はほぼ同じ結果がでるところだが、ここではいずれの
361 環境でも新しいバージョンの方が速い。15~20\%ほど高速化していることがわ 360 環境でも新しいバージョンの方が速い。15--20\%ほど高速化していることがわ
362 かる。これは本研究で行った改善の一つ、fastcallの影響である。 361 かる。これは本研究で行った改善の一つ、fastcallの影響である。
363 362
364 363
365 364
366 365