# HG changeset patch # User kent # Date 1265448523 -32400 # Node ID 30c102343b37cb3e8b8b2e66c0be9bfe2fa6b653 # Parent d2999e94b97d6017030a30b9c83035e9e64fe996 modify gcc. fix references. diff -r d2999e94b97d -r 30c102343b37 appendix.tex --- a/appendix.tex Sat Feb 06 04:47:35 2010 +0900 +++ b/appendix.tex Sat Feb 06 18:28:43 2010 +0900 @@ -1,6 +1,6 @@ \chapter{付録} -\section{\texttt{\_\_return}擬似変数の実装} +\section{\texttt{\_\_return}擬似変数の実装}\label{apx:postfix-expression} % 環境付き継続の実装、内部関数の自動追加処理 環境付き継続の実装のための、\verb|__return|擬似変数を追加する処理を @@ -16,10 +16,23 @@ {sources/nest-and-goto.c} -\section{quicksort例題} +\section{プロトタイプ生成スクリプト}\label{apx:make-prototype} + +\ref{sec:prototype}節で紹介したPythonスクリプトをコード +\ref{code:make-prototype}に掲載する。 -速度、ファイルサイズの性能評価に用いたCbCによるquicksortの例題プログラム -をコード\ref{code:quicksort}に掲載する。 +\lstinputlisting + [caption=プロトタイプ生成スクリプト, + label=code:make-prototype] + {sources/make-prototype.py} + + + +\section{quicksort例題}\label{apx:quicksort} + +\ref{chp:eval}章での速度、ファイルサイズの性能評価に用いたCbCによる +quicksortの例題プログラムをコード\ref{code:quicksort-cbc}, +\ref{code:quicksort-test}に掲載する。 \lstinputlisting [caption=quicksort\_cbc.cbc, diff -r d2999e94b97d -r 30c102343b37 bibliography.tex --- a/bibliography.tex Sat Feb 06 04:47:35 2010 +0900 +++ b/bibliography.tex Sat Feb 06 18:28:43 2010 +0900 @@ -18,7 +18,15 @@ \bibitem{bib:shimoji-2007} 下地篤樹, 河野真治. ``線形時相論理によるContinuation based Cプログラムの検証''. 情報処理学会システムソフトウェアとオペレーティング・システム研究会(OS), April, 2007. - \bibitem{bib:kinjo-2004} + \bibitem{bib:akira-2008} + 神里晃 宮國渡, 杉山千秋, 河野真治. + ``CからCellアーキテクチャを利用したCbCへの変換'' + 電子情報通信学会VLSI設計技術研究会, March, 2008 + \bibitem{bib:kono-2006} + 河野真治, 渕田良彦, 宮國渡. + ``継続を基本とする言語 CbC による分散プログラミング''. + 日本ソフトウェア科学会第23回大会論文集, Sep, 2006 + \bibitem{bib:kinjo-2005} 金城拓実, 河野真治. ``ゲームプログラムからの一部の仕様の抽出に関する考察''. 日本ソフトウェア科学会第22回大会論文集, Sep, 2005 diff -r d2999e94b97d -r 30c102343b37 cbc.tex --- a/cbc.tex Sat Feb 06 04:47:35 2010 +0900 +++ b/cbc.tex Sat Feb 06 18:28:43 2010 +0900 @@ -108,7 +108,7 @@ \subsection{コードセグメント} CbCは図\ref{fig:continuation}の様に分割された手続きのそれぞれを一つの -処理単位として用い、これを``コードセグメント''(code-segment)と呼ぶ。 +処理単位として用い、これを``コードセグメント(code-segment)''と呼ぶ。 コードセグメントはキーワード``code''を用いてCの関数の様に定義される。 引数部分はインタフェイスと呼ばれ、継続前のコードセグメントからの出力に @@ -125,7 +125,7 @@ \subsection{軽量継続(light-weight continuation)} コードセグメントはCにおける関数とは違い、呼出し元への復帰は存在しない。 そのためコードセグメントの処理の末尾で別のコードセグメントへ継続するこ -とになる。CbCではこの継続制御を``軽量継続''(light-weight continuation) +とになる。CbCではこの継続制御を``軽量継続(light-weight continuation)'' と呼ぶ。 軽量継続はキーワード``goto''のあとにコードセグメント名とそのコードセグ @@ -196,14 +196,14 @@ \subsection{環境付き継続}\label{ssec:gotowithenv} 環境付き継続を用いる場合、Cの関数からコードセグメントへ継続する際に -\_\_returnという名前で表される特殊なコードセグメントポインタを渡す。コ -ード\ref{code:cbcreturn}では関数\verb|funcB|からコードセグメント +\verb|__return|という変数で表される特殊なコードセグメントポインタを渡 +す。コード\ref{code:cbcreturn}では関数\verb|funcB|からコードセグメント \verb|cs|に継続する際に\verb|__return|を渡している。 継続先のコードセグメントでは渡されたコードセグメントポインタへ継続する 事で元のCの環境に復帰することが可能となる。 -ただし復帰先は\_\_returnを参照した関数が終了する位置である。このプログ -ラムの例では、関数\verb|funcA|からは\verb|funcB|が正常に終了したように -見える。図\ref{fig:cbcreturn}にこの様子を表した。 +ただし復帰先は\verb|__return|を参照した関数が終了する位置である。この +プログラムの例では、関数\verb|funcA|からは\verb|funcB|が正常に終了した +ように見える。図\ref{fig:cbcreturn}にこの様子を表した。 \lstinputlisting [caption=\_\_returnの例, label=code:cbcreturn, @@ -239,7 +239,8 @@ ればこの探索に有利となる。 本研究室の下地らはこの特徴を持つCbCを用いて線形時相論理による検証を提 -案し、その有用性を示した。\cite{bib:shimoji} +案し、その有用性を示した。\cite{bib:shimoji-2006}, +\cite{bib:shimoji-2007} \subsection{ゲームプログラミングにおけるデモンストレーション} @@ -250,7 +251,7 @@ その問題の解決に、ゲームプログラム全体を小規模なプログラムの集合である ``デモンストレーション''に分割するという手法を本研究室の金城らが提案し -た。\cite{bib:kinjo},\cite{bib:chiaki} +た。\cite{bib:kinjo-master-2005},\cite{bib:akira-2008} このデモンストレーション手法はプログラムを細かく分割するため、ゲーム機 や組み込みなどの資源が制約された環境ではサブルーチンによるスタック操作 @@ -271,15 +272,17 @@ \subsection{micro-cとGCC} -CbCのコンパイラには二つの実装が用意されている。 -一つは2000年に当研究室の河野らにより開発された、micro-cというCのコンパ -イラをベースとしたものである。こちらは現在安定して動作しており、アーキ -テクチャは PowerPC, x86, MIPS, ARMなどに対応している。 -もう一つは2008年に開発された、GCCをベースとしたコンパイラである。 -micro-cはバグも少なく安定しているのだが、GCCは元より豊富な最適化機構や -多数のアーキテクチャをサポートしており、その要望により開発された。 +CbCのコンパイラには二つの実装が用意されている。一つは2000年に当研究室 +の河野らにより開発された、micro-cというCのコンパイラをベースとしたもの +である。こちらは現在安定して動作しており、アーキテクチャは PowerPC, +x86, MIPS, ARMなどに対応している。もう一つは2008年に開発された、GCCを +ベースとしたコンパイラである。 \cite{bib:kent-2008} -\subsection{GCCベースコンパイラの問題点} +GCCは元より多数のアーキテクチャに対応しており、高機能な最適化も備えて +いる。これらをCbCでも活用したいという要望からコンパイラ環境の移植が行 +われた。 + +\subsection{GCCベースコンパイラの問題点}\label{sec:gcc-problems} この時の実装でコードセグメント、継続制御構造などは実装され、一通りの CbCプログラムのコンパイルが可能となった。 @@ -293,13 +296,13 @@ \item 環境付き継続 これは未実装の機能である。 - 変更された新しい仕様の方に対応したい。 + 仕様に若干変更があったので新しい仕様に対応したい。 \item 並列代入 CbCでは現在のコードセグメントのインタフェイスと次に継続するコード セグメントの引数は同じメモリスペース（もしくはレジスタ）に格納して - いる。そのためコード\ref{code:paralell_example}のように変数の値を + いる。そのためコード\ref{code:parallel-example}のように変数の値を 入れ替えるような処理では並列代入が行われることになる。 前実装では単純な並列代入に対しては問題がなかったが、構造体の混じる 複雑な並列代入ではバグが見つかっている。 diff -r d2999e94b97d -r 30c102343b37 evaluations.tex --- a/evaluations.tex Sat Feb 06 04:47:35 2010 +0900 +++ b/evaluations.tex Sat Feb 06 18:28:43 2010 +0900 @@ -139,14 +139,14 @@ ので割愛している。また、GCC-4.2.3ベースコンパイラはppcでは実行不能であ ったためx86のみとなる。 -各評価マシンの詳細は付録\ref{sec:}に掲載する。 +各評価マシンの詳細は付録\ref{sec:machine-specs}に掲載する。 %gccのコンパイルでは``-O2 -fomit-pointer''の最適化を付加して測定している。 % noreturnもON. % x86ではfastcallもON, \subsection{評価結果} -実効速度の測定結果を表\ref{tab:eval-speed}に示す。 +実効速度の測定結果を表\ref{tab:speed-mc-vs-gcc}に示す。 ただし環境毎にCPU速度は異なるので、上下の比較には意味はない。 % -O2で約10秒になる要素数を選んだ方がいいかもしれない \begin{table}[htpb] @@ -162,7 +162,7 @@ ppc/PS3 &39.176 & 5.874 & 6.111 &11.121 \\ \hline \end{tabular} \caption{アーキテクチャ毎のgccとmcの速度比較（単位: 秒）} - \label{tab:eval-speed} + \label{tab:speed-mc-vs-gcc} \end{table} 次に実行ファイルのstrip前のファイルサイズを表\ref{tab:eval-nostrip} @@ -200,8 +200,9 @@ \label{tab:eval-strip} \end{table} -最後に、本研究での実装GCC-4.4.2と以前のバージョンGCC-4.2.3との比較であ -る。こちらはx86のみ、最適化も-Osは対応していない。 +最後に、本研究での実装GCC-4.4.2と以前のバージョンGCC-4.2.3との比較を表 +\ref{tab:speed-old-vs-new}に示す。こちらはx86のみ、最適化も-Osは対応し +ていない。 \begin{table}[htpb] \centering \begin{tabular}{|c|c|c|c|c|} \hline @@ -213,7 +214,7 @@ x86/Linux & 5.715 & 2.401 & 4.525 & 2.851 \\ \hline \end{tabular} \caption{GCC-4.2.3ベースとGCC-4.4.2ベースの速度比較（単位: 秒）} - \label{tab:eval-speed} + \label{tab:speed-old-vs-new} \end{table} @@ -232,7 +233,7 @@ まずどのアーキテクチャにおいても、GCCの最適化が大きな速度差を生み出し ている事が分かる。最適化なしと速度最適化を比較すると、x86では2.4倍、 ppcでは5〜7倍もの差が生じている。 -ただしppcのこの以上な速度差は\ref{ssec:}並列代入で示した様に、継続の引 +ただしppcのこの以上な速度差は\ref{sec:impl-parallel}並列代入で示した様に、継続の引 数を全て一時変数に入れていることが大きい。その場合最適化なしではすべて の引数を一度メモリに確保するので、その分逆に遅くなっているのだと考えら れる。しかしながら最適化を有効にすることでそのメモリへの一時変数の確保 diff -r d2999e94b97d -r 30c102343b37 implementation.tex --- a/implementation.tex Sat Feb 06 04:47:35 2010 +0900 +++ b/implementation.tex Sat Feb 06 18:28:43 2010 +0900 @@ -24,10 +24,9 @@ る。このcodeは内部でvoid型に変換する。 GCC（及び一般的なコンパイラ）ではコンパイルに必要な全ての要素、変数や式 -、関数、構文などをすべて treeと呼ばれる構文木に保持している。コードセ -グメントの構文木も関数とほ -ぼ同じものを作成すれば良い。コード\ref{code:build-code-segment}はその -構文木を作成している部分である。 +、関数、構文などをすべて GIMPLEと呼ばれる構文木に保持している。コードセ +グメントの構文木も関数とほぼ同じものを作成すれば良い。コード +\ref{code:build-code-segment}はその構文木を作成している部分である。 \lstinputlisting [caption=構文木生成(gcc/c-typeck.c),label=code:build-code-segment] @@ -41,8 +40,6 @@ \subsection{軽量継続の実装} \label{sec:impl-goto} -% return somesegment(); -% expand_call() 軽量継続はGCCの末尾呼び出し最適化の機構を用いて実装する。 @@ -95,8 +92,8 @@ \item スタックのサイズをごまかす tailcallは呼び出し元の全引数サイズが呼び出し先のそれより小さい場合 - には実行できない。そのため呼び出し元、この場合コードセグメント全て - の引数にもちいるスタックサイズを大きな値でごまかす。 + には実行できない。そのため呼び出し元のコードセグメント全ての引数に + もちいるスタックサイズを大きな値でごまかす。 \item 並列代入 \ref{sec:cbc-problem}で説明したような並列代入の必要な関数呼び出し @@ -135,7 +132,7 @@ % 最適化の期待 % おい、replace_arguments関数、あんまり意味ないぞ -\ref{sec:}のコード\ref{code:}で説明した様に、コードセグメントの受け取 +\ref{sec:gcc-problems}節で説明した様に、コードセグメントの受け取 った引数と継続の際に渡す引数の順序が変わる場合等に並列代入が必要になる。 過去の実装ではこの並列代入を、\verb|expand_call|という構文木から中間コ ードを生成する処理の部分で行っていた。 @@ -217,8 +214,6 @@ 成した際にこの関数\verb|cbc_replace_arguments|を実行することで、この軽 量継続は並列代入に対応できるようになった。 -この影響による速度変化の評価は\ref{sec:compare2old}節で行う。 - \subsection{環境付き継続} @@ -231,7 +226,7 @@ 渡された\verb|__return|の値は、コードセグメント側からは他のコードセグ メントと区別する必要はない。 -この環境付き継続にもちいる\verb|_ _return|擬似変数の実装には様々な方法 +この環境付き継続にもちいる\verb|__return|擬似変数の実装には様々な方法 が考えられるが、今回の実装には内部関数をもちいることにした。内部関数は GCCによるCの拡張機能である\cite{bib:nestedfunc}。 @@ -311,53 +306,46 @@ \subsection{PowerPCにおける間接継続}\label{sec:impl-indirect} -軽量継続の実装にtailcallを用いたことは\ref{sec:}で説明した。しかし、実 -際にはtailcallが行われないアーキテクチャがいくつか存在する。 PowerPCも -その一つで、このアーキテクチャでは間接呼び出しの場合は tailcallが行わ -れない。このためこれまでPowerPCでの間接継続はコンパイルエラーで実行で -きなかった。 +軽量継続の実装にtailcallを用いたことは\ref{sec:impl-goto}で説明した。 +しかし、実際にはtailcallが行われないアーキテクチャがいくつか存在する。 +PowerPCもその一つで、このアーキテクチャでは間接呼び出しの場合は +tailcallが行われない。このためこれまでPowerPCでの間接継続はコンパイル +エラーで実行できなかった。 間接呼び出しのtailcallは専用のRTL表現がある。 PowerPCで問題となるのは、このRTLからアセンブラへの変換が定義されていな -いことである。この問題に対処するため、PowerPCアーキテクチャにおけるmc +いことである。この問題に対処するため、PowerPCアーキテクチャにおけるmd を記述する。 -\subsubsection{RTLとMachine Description} -GCCは構文木からRTLと呼ばれる中間コードを生成する。この中間コードは一部 -を除いてアーキテクチャ依存性はなく、どのアーキテクチャでもほぼ同じにな -る。さらに、最終的にこのRTLはアーキテクチャ毎に異なる規則でアセンブラ -に変換される。この規則を定義するのがMachine Description（以下md）であ -る。 +\subsubsection{間接tailcallのRTLとMachine Description} -RTL、およびmdはどちらもS式で表現されている。 -GCCは自身のビルドの際、S式をパースするプログラムを作成し、そのプログラ -ムはmdを基にアーキテクチャ毎に異なるCのソースコードを出力する。このソ -ースコードがコンパイルされてGCCの一部となる。 +GCCでは関数呼び出しは全て一つのRTLに置き換えられる。 +これはtailcallが行われた場合も、呼び出し関数がポインタである場合も同様 +である。しかしtailcallかポインタかによってRTLの形が異なるため、 +PowerPCではこの両方の場合（つまり間接呼び出しのtailcall）のRTLの形が +mdで定義されていない。そのため、これはエラーになる。 -RTLの例としてこの問題となっている間接継続を表すS式をコード -\ref{code:rtl-indirecttailcall}に示す。 +この問題となっているRTLを次のコード\ref{code:rtl-indirecttailcall}に +示す。 \lstinputlisting [caption=PowerPCにおける間接継続のRTL, label=code:rtl-indirecttailcall, language=Lisp] {sources/rtl-indirecttailcall.rtl} - -% TODO: RTLの説明も入れるか？ +このRTL内の\verb|(mem:SI (reg/f:SI 129)|が関数のポインタを示すレジスタ +である。間接呼び出しでない場合はこれが +\verb|(mem:SI (symbol_ref:SI (``cs0'')|となり、コードセグメントの関数 +を直接表している。 \subsubsection{間接継続のmd} -mdにはこのRTLをアセンブラに変換するための情報を定義する。 -定義すべき情報は以下の4つである。 -\begin{itemize} - \item 規則の名前 - \item 変換するRTL - \item 変換する条件 - \item 出力するアセンブラを返すCの構文 -\end{itemize} -同じくmdの例として、この問題となったRTL用の変換規則を定義したものをコ -ード\ref{code:md-example}に示す。 +PowerPCにおいて間接継続を実装するには、上記のRTLを変換するmdを記述すれ +ば良い。このRTLに近い形が間接でないtailcallのmdとして使われているはず +なのでそれを使用する。 次のコード\ref{code:md-example}が新しく記述され +たmdである。 + \lstinputlisting - [caption=\ref{code:rtl-for-indirect}の変換規則, + [caption=\ref{code:rtl-indirecttailcall}の変換規則, label=code:md-for-indirect, language=Lisp] {sources/md-for-indirect.md} @@ -367,8 +355,9 @@ ここでは出力するアセンブラとして\verb|b%T0|が使われている。 \verb|%T0|はレジスタ名に置き換えられる部分である。このアセンブラは最終 -的には\verb|bctr|と置き換えられてPowerPCのアセンブラとして出力される。 -%間接でない、通常の継続ではこれが\verb|bl%T0|となっているので対照的であ +的には\verb|bctr|と置き換えられてPowerPCのアセンブラとして出力されるこ +とになる。 +%間接でない、通常の継続ではこれが\verb|b%T0l|となっているので対照的であ %る。コード\ref{code:md-example}は実際に通常の継続用のmd修正して作られ %た。 @@ -436,7 +425,7 @@ レジスタ\verb|ecx,edx|に引数をのせることが可能となる。 -\subsection{プロトタイプ自動生成} +\subsection{プロトタイプ自動生成} \label{sec:prototype} Cのプロトタイプ宣言はコンパイル時のエラー検出に役立っている。 しかしCbCのコードセグメントには返り値は存在しない。また状態遷移記 述という性質上、プログラムを記述する際は上から下に実行順にコードセ @@ -452,7 +441,7 @@ 行うスクリプトを作成した。このスクリプトでは関数の定義部を正規表現で検 索し、マッチする部分を変換して関数宣言として出力する。 -全コードは付録\ref{apx:}に掲載する。 +全コードは付録\ref{apx:make-prototype}に掲載する。 % TODO: prototype declaration diff -r d2999e94b97d -r 30c102343b37 introduction.tex --- a/introduction.tex Sat Feb 06 04:47:35 2010 +0900 +++ b/introduction.tex Sat Feb 06 18:28:43 2010 +0900 @@ -54,12 +54,8 @@ これまでCbCのコンパイルにはmicro-cをベースとしたコンパイラとGNUコンパ イラコレクション（以下gcc）をベースとしたコンパイラが用いられてきた。 -しかしgccにはバグや当初の期待ほど速度がでないという問題があり、また研 -究段階であるCbC言語自体にも仕様の変更などがあった。 - -%しかしgccは実用的なプログラムを動かすにはまだバグが多く、当初の期待ほ -%ど速度もでないという問題がある。また、研究段階であるCbC言語自体にも仕 -%様の変更などがあった。 +しかしgccにはバグや当初の期待ほど速度がでないという問題があり、研究段 +階であるCbC言語自体にも仕様の変更などがあった。 本論文ではGCCベースのCbCコンパイラの問題の洗い出しとその問題の改善を行 い、実用レベルのCbCプログラムの動作を目指す。また、CbCを用いたプログラ @@ -68,47 +64,9 @@ の速度比較を行い、 同じくTaskManager開発を通してのCbCによるプログラミ ングの記述性についても評価・考察を行う。 -%また、CbCを用いた応用例として現在開発中のCbCベース TaskManagerを紹介 -%し、 micro-cとの速度比較による評価を行う。さらにCbC の使用例として現 -%在開発中のCbCによる TaskManagerを紹介し、CbCによるプログラミングの記 -%述性についても論じる。 - - - - -%我々はこれまで、様々な視点から軽量継続を用いた言語、Continuation based -%Cの有用性について研究してきた。このContinuation based C(以下CbC)はCか -%らサブルーチンやループ構造を除いたCの下位言語であり、ハードウェアとソ -%フトウェアの記述、また記述したプログラムの検証を目的として本研究室が提 -%案している言語である。 - -%\section{先行研究とCbC開発の動機} - -%\subsection{プログラムの検証} -%計算機科学の進歩により、ソフトウェアは大規模かつ複雑なものになっている。しかしそれに応じて、設計段階において誤りが生じる可能性も高くなってきており、設計されたシステムに誤りがないことを保証するための論理設計や検証手法及びデバッグ手法の確立が重要な課題となっている。 - -%どんなプログラムでも状態と状態遷移が存在し、その全てを網羅的に探索することでデッドロックなどの望ましくない状態を検出することができる。探索にはさまざまな手法が考えられるが、プログラムを直接状態遷移として記述できればこの探索に有利となる。 - -%本研究室の下地らはこの特徴を持つCbCを用いて線形時相論理による検証を提案し、その有用性を示した。\cite{bib:shimoji} - - -%\subsection{ゲームプログラミングにおけるデモンストレーション} -%我々は家庭用ゲーム機で動作するゲームプログラムのオープンな開発フレームワークに関する研究も行ってきた。 -%家庭用ゲーム機の多くは特殊なアーキテクチャをもち、そのためゲームプログラムには汎用性や冗長性が極めて小さく、移植が困難という問題がある。 - -%その問題の解決に、ゲームプログラム全体を小規模なプログラムの集合である``デモンストレーション''に分割するという手法を本研究室の金城らが提案した。\cite{bib:kinjo},\cite{bib:chiaki} - -%このデモンストレーション手法はプログラムを細かく分割するため、ゲーム機や組み込みなどの資源が制約された環境ではサブルーチンによるスタック操作がネックとなる。 -%そのためこの手法ではプログラム分割の実現にCbCを用いており、CからCbCへの機械的な変換方法について述べている。 - - -%\subsection{ハードウェア記述、ソフトウェアプログラミング} - -%\subsection{軽量継続を用いたプログラミング} -%以上の研究はそれぞれ軽量継続というCbC言語の特徴を利用して進められている。 \section{論文構成} diff -r d2999e94b97d -r 30c102343b37 memo.txt --- a/memo.txt Sat Feb 06 04:47:35 2010 +0900 +++ b/memo.txt Sat Feb 06 18:28:43 2010 +0900 @@ -188,75 +188,16 @@ o 用語の統一 - gcc, GCC - ppc, PowerPC - - mc, micro-c + - mc, micro-c, Micro-C - 末尾呼び出し最適化, tailcall - 継続制御, 軽量継続 - - - -\begin{table}[htpb] - \centering - \begin{tabular}{|c|c|c|c|c|c|} \hline - \multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ} } - & \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{mc} \\ \cline{2-5} - & \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} & \\ \cline{2-5} - & -O2 & -Os & -O2 & -Os & \\ \hline - x86/OS X & 11100 & 11100 & 9804 & 9804 & \\ \hline - x86/Linux & 18444 & 17310 & 8216 & 8214 & \\ \hline - ppc/OS X & 10392 & 10392 & 9172 & 9172 & \\ \hline - ppc/Linux & 25138 & 23876 & 13030 & 13028 & \\ \hline - ppc/PS3 & 22142 & 20452 & 9906 & 9672 & \\ \hline - \end{tabular} - \caption{実行ファイルのファイルサイズ比較 not stripped（単位: bytes）} - \label{tab:eval-strip} -\end{table} -\begin{table}[htpb] - \centering - \begin{tabular}{|c|c|c|c|c|c|} \hline - \multirow{3}{*}{ \backslashbox{CPU/OS}{コンパイラ} } - & \multicolumn{4}{c|}{GCC} & \multirow{3}{*}{mc} \\ \cline{2-5} - & \multicolumn{2}{c|}{デバグ情報(-g)付き} & \multicolumn{2}{c|}{デバグ情報なし} & \\ \cline{2-5} - & -O2 & -Os & -O2 & -Os & \\ \hline - x86/OS X & 9176 & 9176 & 9176 & 9176 & \\ \hline - x86/Linux & 5752 & 5752 & 5752 & 5752 & \\ \hline - ppc/OS X & 8576 & 8576 & 8576 & 8576 & \\ \hline - ppc/Linux & 10068 & 10068 & 10068 & 10068 & \\ \hline - ppc/PS3 & 6960 & 6728 & 6960 & 6728 & \\ \hline - \end{tabular} - \caption{実行ファイルのファイルサイズ比較 stripped（単位: bytes）} - \label{tab:eval-strip} -\end{table} + - 当研究室、本論文 + o 要旨 + o まとめ + o 論文構成 + o 先行研究、分散プログラミング + o 最適化パス -\begin{table}[htpb] - \centering - \begin{tabular}{|c|c|c|c|c|} \hline - \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } - & \multicolumn{3}{c|}{gcc} & \multirow{2}{*}{mc} \\ \cline{2-4} - &最適化なし&速度最適化&サイズ最適化& \\ \hline - x86/OS X & 11352 & 11100 & 11100 & 11100 \\ \hline - x86/Linux & 19634 & 18444 & 8214 & 9800 \\ \hline - ppc/OS X & 14720 & 10392 & 10392 & 14396 \\ \hline - ppc/Linux & 22498 & 25138 & 23876 & 19754 \\ \hline - ppc/PS3 & 20758 & 21507 & 9672 & 18516 \\ \hline - \end{tabular} - \caption{実行ファイルのファイルサイズ比較 not stripped（単位: bytes）} - \label{tab:eval-nostrip} -\end{table} -\begin{table}[htpb] - \centering - \begin{tabular}{|c|c|c|c|c|} \hline - \multirow{2}{*}{ \backslashbox{CPU/OS}{コンパイラ} } - & \multicolumn{3}{c|}{gcc} & \multirow{2}{*}{mc} \\ \cline{2-4} - &最適化なし&速度最適化&サイズ最適化& \\ \hline - x86/OS X & 9256 & 9176 & 9176 & 9176 \\ \hline - x86/Linux & 9856 & 5752 & 5752 & 5752 \\ \hline - ppc/OS X & 12736 & 8576 & 8576 & 12664 \\ \hline - ppc/Linux & 10072 & 10068 & 10068 & 9920 \\ \hline - ppc/PS3 & 9064 & 6960 & 6728 & 7944 \\ \hline - \end{tabular} - \caption{実行ファイルのファイルサイズ比較 stripped（単位: bytes）} - \label{tab:eval-strip} -\end{table}