comparison paper/test.tex @ 5:f515d7e7e4df

finish chapter 6.
author koba <koba@cr.ie.u-ryukyu.ac.jp>
date Sun, 06 Feb 2011 01:56:30 +0900
parents 2dbd515e0284
children 2dcc784d62e0
comparison
equal deleted inserted replaced
4:2dbd515e0284 5:f515d7e7e4df
46 \section{乱数生成} 46 \section{乱数生成}
47 乱数のランダム性はバグの再現性を落とすが、乱数生成器を無効にするか、定数で 47 乱数のランダム性はバグの再現性を落とすが、乱数生成器を無効にするか、定数で
48 シードすることによって再現性を下げることなく、テストすることが出来る 48 シードすることによって再現性を下げることなく、テストすることが出来る
49 (\ref{sec:random}節)。 49 (\ref{sec:random}節)。
50 50
51 通常のシーケンシャルなプログラムでは 1 つの乱数列から順番に各 Move 関数が
52 乱数を取得し、使用する。しかし並列プログラムでは Move 関数が Task として
53 SPE に送られる。各 SPE 内では以下のような処理が行われる。
54
55 \begin{enumerate}
56 \item 定数でシードし、乱数列を生成する。
57 \item Task1 で乱数列の先頭から 1 番目の乱数を取得する
58 \item Task2 で乱数列の先頭から 2 番目の乱数を取得する
59 \item Task3 で乱数列の先頭から 3 番目の乱数を取得する
60 \end{enumerate}
61
62 乱数列は SPE 毎に独自に生成されるため、各 Task(=Move) が受け取る乱数は
63 逐次実行した時とは異なる値となってしまう。また、SPE 内でも Task 同士に
64 依存関係を持たせない限り、Task の実行順序が保証されないのでこれも受け取る
65 乱数が不定となる原因となる。(図\ref{fig:spe_random})
66
67 そこで予め PPE 内で乱数列を生成し、inData として Task に渡しておく。
68 Task Dandy では Task の生成、定義がされるタイミングは Super Dandy における
69 Move 関数や Collision 関数が実行されるタイミングと同じである為、渡される乱数
70 は Super Dandy と同じ乱数となる。(図\ref{fig:ppe_random})
71
72 \newpage
73
74 \begin{figure}[h]
75 \begin{center}
76 \includegraphics[scale=0.5]{images/spe_random.pdf}
77 \end{center}
78 \caption{SPE 内での乱数の生成}
79 \label{fig:spe_random}
80 \end{figure}
81
82 \begin{figure}[h]
83 \begin{center}
84 \includegraphics[scale=0.5]{images/ppe_random.pdf}
85 \end{center}
86 \caption{PPE 内での乱数の生成と乱数の受け渡し}
87 \label{fig:ppe_random}
88 \end{figure}
89
90 \newpage
91
92 \begin{figure}[h]
93 \begin{center}
94 \includegraphics[scale=0.8]{images/test_log.pdf}
95 \end{center}
96 \caption{Task Dandy で起こりうるバグ}
97 \label{fig:test_log}
98 \end{figure}
51 99
52 \section{テストログとそのタイミング} 100 \section{テストログとそのタイミング}
53 シーケンシャルなプログラムを Task に分割して並列実行する際に、新たに発生する 101 シーケンシャルなプログラムを Task に分割して並列実行する際に、新たに発生する
54 バグとして、本研究では以下の項目に焦点を当てた。(図\ref{fig:test_log}) 102 バグとして、本研究では以下の項目に焦点を当てた。(図\ref{fig:test_log})
55 103
57 \item Task 間のデータの同期 105 \item Task 間のデータの同期
58 \item Task の実行順序 106 \item Task の実行順序
59 \item Task の定義 107 \item Task の定義
60 \end{itemize} 108 \end{itemize}
61 109
62 \begin{figure}[h]
63 \begin{center}
64 \includegraphics[scale=0.8]{images/test_log.pdf}
65 \end{center}
66 \caption{Task Dandy で起こりうるバグ}
67 \label{fig:test_log}
68 \end{figure}
69
70 このうち、Task の定義については、定義される内容が非常に小さい為、Task の 110 このうち、Task の定義については、定義される内容が非常に小さい為、Task の
71 inData や outData を調べるといった従来の単体テストでも十分にテストが可能で 111 inData や outData を調べるといった従来の単体テストでも十分にテストが可能で
72 ある。その他の 2 つについては、いずれも衝突判定の際に生じるバグである。 112 ある。その他の 2 つについては、いずれも衝突判定の際に生じるバグである。
73 113
74 そこで、オブジェクトが被弾した時、そしてオブジェクトが生成された時にテスト 114 そこで、オブジェクトが被弾した時、そしてオブジェクトが生成された時にテスト
75 ログを取ることで効率的にバグを発見することができると考えた。以下に実際に 115 ログを取ることで効率的にバグを発見することができると考えた。以下に実際に
76 収集したテストログの例を示す。 116 収集したテストログの例を示す。
77 117
78 \begin{verbatim} 118 \begin{verbatim}
79 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000 vx= 0.000000 vy= 4.000000 119 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000
80 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000 vx= 0.000000 vy= 4.000000 120 vx= 0.000000 vy= 4.000000
121 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000
122 vx= 0.000000 vy= 4.000000
81 [TAMA]lv1 = 2, lv2 = 0 [LASER]lv1 = 0 123 [TAMA]lv1 = 2, lv2 = 0 [LASER]lv1 = 0
82 \end{verbatim} 124 \end{verbatim}
83 125
84 それぞれのパラメータの詳細は次のとおりである。 126 それぞれのパラメータの詳細は次のとおりである。
85 127
87 \item F64,F85\\ 129 \item F64,F85\\
88 生成、もしくは被弾した時の経過フレーム。 130 生成、もしくは被弾した時の経過フレーム。
89 \item CREATE,DELETE\\ 131 \item CREATE,DELETE\\
90 CREATE ならオブジェクトが生成された、DELETE ならオブジェクトが被弾した事を 132 CREATE ならオブジェクトが生成された、DELETE ならオブジェクトが被弾した事を
91 表す。 133 表す。
92 \item [NAME]\\ 134 \item NAME\\
93 \item [COORD]\\ 135 オブジェクトの種類と ID。ID はオブジェクトの種類毎に 0 から順番に付けられ
94 オブジェクトが存在した座標とその時の速さの x 成分、y 成分。 136 るのでどのオブジェクトの情報なのかを特定できる。
95 \item [TAMA],[laser]\\ 137 \item COORD\\
96 被弾した際の、画面上に生成されているプレイヤーの弾丸オブジェクトの数を 138 オブジェクトのxy座標とxy方向の速度。
97 表している。 139 \item TAMA,LASER
140 その瞬間に画面内に存在した弾の数。差異があれば同期が取れていないことを
141 示す。
98 \end{itemize} 142 \end{itemize}
99 143
100 これにより、フレーム単位でどのオブジェクトが生成、または被弾したのか知ること 144 これにより、フレーム単位でどのオブジェクトが生成、または被弾したのか知ること
101 ができる。trace モードでプレイヤーの入力を固定し、各バージョンでテストログを 145 ができる。trace モードでプレイヤーの入力を固定し、各バージョンでテストログを
102 取り、その差異を調べることでバグが発生している時間や場所を特定することが 146 取り、その差異を調べることでバグが発生している時間や場所を特定することが
104 148
105 \section{描画処理を行わないビデオモード}\label{sec:video_none} 149 \section{描画処理を行わないビデオモード}\label{sec:video_none}
106 Cerium では Rendering Engine において 3 つの Task を用いて画面の描画処理を 150 Cerium では Rendering Engine において 3 つの Task を用いて画面の描画処理を
107 行っている(\ref{sec:rendering}節)。Cerium では複数の環境で動作するように 151 行っている(\ref{sec:rendering}節)。Cerium では複数の環境で動作するように
108 オブジェクトを画面のフレームバッファに直接書き出すモードや、SDL のバッファに 152 オブジェクトを画面のフレームバッファに直接書き出すモードや、SDL のバッファに
109 書き出すモードなど、複数のビデオモードが存在する。しかし、プレイヤーの入力を 153 書き出すモードなど、複数のビデオモードが存在する。
110 バイナリデータに書き出し、読み出す場合、画面の描画処理は不要となる。 154 (図\ref{fig:video_mode})
111 155
156 しかし、プレイヤーの入力をバイナリデータから読み出す場合、処理の詳細が
157 知りたい場合を除いて画面の描画処理は不要となる。
112 そこでテスト用に画面の描画処理を行わないモードを Cerium に実装した。 158 そこでテスト用に画面の描画処理を行わないモードを Cerium に実装した。
113 これは、Cerium 内で画面のバッファを確保する処理をしている箇所と、描画用の 159 これは、Cerium 内で画面のバッファを確保する処理をしている箇所と、描画用の
114 Task を生成する処理をしている箇所をスルーすることで描画処理と無駄なメモリ 160 Task を生成する処理をしている箇所をスルーすることで描画処理と無駄なメモリ
115 確保を行わないビデオモードである。(図\ref{fig:video_none}) 161 確保を行わないビデオモードである。(図\ref{fig:video_none})
116 162
117 \if0 163 \begin{figure}[h]
164 \begin{center}
165 \includegraphics[scale=0.6]{images/video.pdf}
166 \end{center}
167 \caption{通常のビデオモード}
168 \label{fig:video_mode}
169 \end{figure}
170
118 \begin{figure}[h] 171 \begin{figure}[h]
119 \begin{center} 172 \begin{center}
120 \includegraphics[scale=0.8]{images/video_none.pdf} 173 \includegraphics[scale=0.8]{images/video_none.pdf}
121 \end{center} 174 \end{center}
122 \caption{描画処理を行わないビデオモード} 175 \caption{描画処理を行わないビデオモード}
123 \label{fig:vodeo_none} 176 \label{fig:vodeo_none}
124 \end{figure} 177 \end{figure}
125 \fi