|
95
|
1 2008-02-28 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
2
|
|
|
3 * kernel/ppe/BufferManager.cpp: remove_taskQueue_all()
|
|
|
4 taskQueue の create と free が釣り合って無くて、
|
|
|
5 queue が足りなくなる -> extend_pool -> 足りなく(ry
|
|
|
6 ってのを繰り返してメモリ的なセグメンテーションフォルとが出て
|
|
|
7 なんでかなと思ったら、task->wait_me を消去してなかった。
|
|
|
8 task->wait_i は notify(ry で削除されるんだけど、
|
|
|
9 task->wait_me は、notify(ry に渡した後ほったらかしだった。
|
|
|
10 ってことで、wait_me を全消しする関数を作りましたとさ。
|
|
|
11 気持ち速度が増した気がする。気ね。
|
|
|
12
|
|
|
13
|
|
63
|
14 2008-02-17 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
15
|
|
80
|
16 * Todo: 悩んでる所
|
|
|
17
|
|
|
18
|
|
63
|
19 * fix: kernel/ppe/HTask.cpp
|
|
|
20 今まで、manager->create_task で生成したタスクは
|
|
|
21
|
|
|
22 - dependency の設定
|
|
|
23 manager->set_task_depend(master, slave) // slave は master を待つ
|
|
|
24
|
|
|
25 - 実行キューへの追加
|
|
|
26 manager->spawn_task(master);
|
|
|
27 manager->spawn_task(slave);
|
|
|
28
|
|
|
29 と、manager を介してやっていました。
|
|
|
30 まあそれでもいいんだけど、特に dependency の所は
|
|
|
31 どっちがどっちを待つのかってのは、API見るだけじゃわからない。
|
|
|
32 そこで、Task (HTask のこと) に、上二つに対応するような
|
|
|
33
|
|
|
34 void set_depend(HTaskPtr) と void spawn(void) を追加しました。
|
|
|
35
|
|
|
36 - Usage
|
|
|
37 slave->set_depend(master); // slave は master を待つ
|
|
|
38 slave->spawn(); // slave をキューへ追加
|
|
|
39
|
|
|
40 結局は、それぞれの関数の中では、上の set_task_depend とかを
|
|
|
41 呼んでるんだけど、ユーザ側からするとこの方がわかりやすいと思います。
|
|
|
42
|
|
56
|
43 2008-02-16 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
44
|
|
|
45 * tag: beta3
|
|
|
46 ダブルバッファリングを追加し、まあなんとか動いてるんじゃない？って
|
|
|
47 ところまでですが、所詮 Fifo バージョンなので、
|
|
|
48 そろそろ Cell を書き上げて、並列にちゃんと動いてるか確かめないとね
|
|
|
49
|
|
|
50 * add: kernel/ppe/DmaBuffer.cpp
|
|
|
51 ダブルバッファリング用に作ったんだけど、
|
|
|
52 せっかくなので、DMA は、このオブジェクト(が持つ二つの領域)でしか
|
|
|
53 行えないようにする。ってのでどうでしょう。って話を先生としました。
|
|
|
54 並列処理だし、ダブルバッファリングがデフォでいいでしょう。
|
|
|
55 というか、したくなければ swap_buffer とかしなければおk。
|
|
|
56
|
|
62
|
57 -Usage
|
|
|
58 DmaBuffer *buffer = manager->allocate(sizeof(SceneGraphPack));
|
|
|
59
|
|
|
60 今までと違い、create_task の in_addr と out_addr には
|
|
|
61 DmaBuffer をいれてください。ユーザが自分で malloc/new したやつは
|
|
|
62 エラーを出すようにしてる(seg faultだけどね！)
|
|
|
63 汚いソースだが、実際に使ってる様子は Test/simple_render の
|
|
|
64 viewer.cpp で使ってます。sgp_buff と pp_buff ってやつね。
|
|
|
65
|
|
|
66 もうすこしユーザに優しいAPIを作りたい・・・
|
|
|
67
|
|
29
|
68 2008-02-11 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
69
|
|
|
70 * add: Test/simple_render
|
|
|
71 chiaki の DataPack を使った Cube の表示プログラム。
|
|
|
72 簡単に DataPack を TaskManager の scheduler (SpeManager) に渡して
|
|
|
73 処理してコピーして、を繰り返してるだけなんだけど
|
|
|
74 まあ動いてる気がするのでいいんじゃないでしょうか。
|
|
|
75
|
|
56
|
76
|
|
23
|
77 2008-02-10 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
78
|
|
|
79 * tag: beta1
|
|
|
80 この状況だと、できることよりもできないことを書くべき？違うか。
|
|
|
81
|
|
|
82 - task (親) 中で task (子) を生成することはできない
|
|
|
83 正確には「生成はできる」だけど、その 子task が
|
|
|
84 親task に依存している別の task を無視して動くので
|
|
|
85 ちゃんとした結果にならないと。
|
|
|
86 8日の Todo にも書いてあるけど、今の実装では
|
|
|
87 task が task を生成することを想定してない感じなので。
|
|
|
88 完全に spe 用にのみ狙いを絞った実装であって
|
|
|
89 OS って言えない実装であるからして、書き直すの？
|
|
|
90 全ての関数を task しようとするとこうなる訳で、
|
|
|
91 ある部分だけやるってのはまあできるんだろうけど、うーん。
|
|
|
92
|
|
|
93 - chiaki の simple_render が動かない
|
|
24
|
94 (追記) 解決しました
|
|
|
95 単に read/write buffer のサイズが足りないだけだった。アホスwww
|
|
|
96 まあ辱めの為の下は残しておこう
|
|
56
|
97
|
|
23
|
98 まだ cvs に commit してないけど、chiaki が書いた、
|
|
|
99 DataPack 対応の simple_render に TasKManager を組み込んでみた。
|
|
|
100 といっても、OSっぽく書いたんじゃなく、今は
|
|
|
101 update_sgp と create_pp だけを task 化してみた。
|
|
|
102 でまあ動いてるような気はするけど、ものすっごい malloc 系の warning が。
|
|
|
103 時々長く動くよねみたいな感じになってしまっている。
|
|
|
104 TaskManager が悪いのか、simple_render が悪いのか。
|
|
|
105 この TaskManager、ある部分での malloc 系の問題に敏感だなあ。
|
|
|
106 まあそうでなかったらバグの探しようも無いし、良いっちゃー良いんだが。
|
|
56
|
107
|
|
|
108
|
|
16
|
109 2008-02-08 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
110
|
|
|
111 * add: kernel/ppe/SymTable.cpp
|
|
|
112 今まで func[] = {add, sum, ...}
|
|
|
113 とかやってかっこわるい言われまくってたので
|
|
|
114 話し合いの通り Symbol Table みたいなものを作ることに
|
|
|
115
|
|
|
116 // 疑似コードね
|
|
|
117 struct sym_table {
|
|
|
118 char *sym; // シンボル
|
|
|
119 void *address; // シンボルが示すアドレス
|
|
|
120 } sym_table[] = {{"Sum", &Sum} , {"Draw", &draw}};
|
|
|
121
|
|
|
122 int fd = get_fd("Sum");
|
|
|
123 void *addr = get_address(fd);
|
|
56
|
124
|
|
16
|
125 table には "Sum" と "Draw" っていう二つのシンボルが登録されている。
|
|
|
126 例えば、ユーザ(カーネル？)が "Sum" ってシンボルにアクセスしたい場合、
|
|
|
127 まずは get_fd で "Sum" に対する、file descripter を返す。
|
|
|
128 ユーザは、その fd に従って get_address を取得することが出来る。
|
|
|
129 TaskManager 的な使い方をするなら
|
|
|
130
|
|
|
131 // 俺は今、Draw 関数を使うタスクを生成したい
|
|
|
132 int fd = manager->open("Draw");
|
|
|
133 manager->create_task(fd, size, in, out, func);
|
|
|
134 manager->open では get_fd と同じ使い方です。
|
|
|
135
|
|
|
136 まだ改良の余地ありそうですが、今は動いてるってことで。
|
|
|
137
|
|
|
138
|
|
|
139 - 補足
|
|
|
140 なぜ file descripter と表すか
|
|
|
141
|
|
|
142 OS の昨日として、 fopen とかと同じ使い方もできるじゃない！
|
|
|
143
|
|
56
|
144
|
|
16
|
145 * Todo: task が task を生成する際の処理
|
|
|
146 今まで、 task が行う作業は、演算のみを行うような
|
|
|
147 単純な実装に決め打ちされているわけです。
|
|
|
148 しかし、OS なんかだと、タスク中から別のタスクを生成するとか
|
|
|
149 ありありだと思われる。てか今のテストプログラムでなった。
|
|
|
150
|
|
|
151 Test/Sum にあるプログラムで使われるタスク
|
|
|
152
|
|
|
153 - init2 // 貧相な名前ですまない
|
|
|
154 演算する数値とかバッファの初期化
|
|
|
155
|
|
|
156 - sum1
|
|
|
157 ある範囲の整数 (i から i+16 とか) の総和
|
|
|
158
|
|
|
159 - sum2
|
|
|
160 sum1 で求められた、複数の範囲の総和を一つにまとめる
|
|
|
161 (ex. 複数の sum1 が 1->16, 17->32, 33->48 の総和を計算し、
|
|
|
162 sum2 で 上の3つの総和を計算する
|
|
|
163 要は 1->48 の総和を分割するっていうプログラムね
|
|
|
164
|
|
|
165 - finish
|
|
|
166 sum2 で求まった値を表示
|
|
|
167
|
|
|
168 この Sum というプログラム、というか OS と言おう。SumOS ね。
|
|
|
169 SumOS は最初に TaskManager (所謂 kernel) を起動し、
|
|
|
170 init を起動する。init では、予め決められたタスクである
|
|
|
171 init2 と finish の二つのタスクを create して登録する。
|
|
|
172 init2 と finish には依存関係がある (init2 が終わったら finish)
|
|
|
173 init2 の中で、sum1 と sum2 というタスクが作られる。
|
|
|
174 sum1 と sum2 にも依存関係はある (sum1 が終わったら sum2)
|
|
56
|
175
|
|
16
|
176 今の実装だと、タスクが終了して初めて次のタスクへ行く。
|
|
|
177 まあ当たり前なんだけど、例えばそのタスクの中で
|
|
|
178 新たにタスクが作られた場合、そのタスクが終了するまでは
|
|
|
179 実行されなくなってしまう。
|
|
|
180 でまあ、今は、manager->create_task される度に
|
|
|
181 manager->run とかして、無理やり起動してる訳さ。
|
|
|
182 何が無理矢理かっていうと、scheduler の役目をしている
|
|
|
183 SpeManager (これも名前変えないと) を2度呼び出してる訳。
|
|
|
184 つまり、タスク中でタスクを作る度に、SpeManager オブジェクトを
|
|
|
185 new してるわけさ。いいのか？いや、動いてるけどね？
|
|
|
186
|
|
|
187 ちなみに、Cell version だと spe が勝手に取っていってくれるから
|
|
|
188 大丈夫かなと思いつつ、もし spe を1つしか使わない設定だったら微妙。
|
|
|
189
|
|
|
190 要するに、タスク中でタスクが作られる場合の処理を考えないとね。
|
|
56
|
191
|
|
13
|
192 2008-02-07 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
193
|
|
|
194 * memo: プログラミングの姿勢
|
|
|
195 scheduler とか、task の管理をする部分は
|
|
|
196 kernel programing のつもりで、
|
|
|
197 example とか、task に割り当てる処理を決めたりする部分は
|
|
|
198 user programing のつもりで。
|
|
|
199
|
|
|
200 それぞれ違った視点で見る必要がある
|
|
|
201
|
|
|
202 * memo: OS というもの
|
|
|
203 OS 起動の流れ
|
|
|
204
|
|
|
205 - PC の電源を入れる
|
|
|
206 - BIOS が立ち上がる (OpenFirmWare, EFI, BIOS)
|
|
|
207 - 起動デバイスをチェック (優先度とか種類とか)
|
|
|
208 - 起動デバイスから Boot loader を起動
|
|
|
209 + BIOS によって、認識できるファイルシステムが違う(だっけ？)
|
|
|
210 + ファイルシステムのどこに Boot Loader があるか知っている
|
|
56
|
211 + grub, grub2, lilo, kboot などがある
|
|
13
|
212 - Boot Loader が kernel を起動
|
|
|
213 + ネットワークブートの場合、TCP/IP や
|
|
|
214 ネットワークデバイス(イーサとか？)のドライバを持ってる必要がある
|
|
|
215 - kernel は、最初に scheduler を起動する
|
|
|
216 - scheduler の初期化 (init を呼ぶ？)
|
|
|
217 - init では、事前？に設定されているスクリプトとかを呼ぶ
|
|
|
218 + linux とかだと /etc/rc にあるやつを init が呼ぶ
|
|
|
219 - login form が起動
|
|
|
220
|
|
|
221 補足 こっからユーザ
|
|
|
222 - login する
|
|
|
223 - shell を呼ぶ
|
|
|
224 + login shell かどうか確かめる
|
|
|
225 - ユーザに設定されてる起動スクリプト？を実行
|
|
|
226 - 晴れてログイン
|
|
|
227
|
|
10
|
228 2008-02-06 Wataru MIYAGUNI <gongo@cr.ie.u-ryukyu.ac.jp>
|
|
|
229
|
|
|
230 * kernel/spe/*.cpp: new と placement new
|
|
|
231 現在、spe kernel のタスクは、切り替わる毎に
|
|
|
232 new/delete を繰り返しています。今はこれでいいんだけど、
|
|
|
233 速度的にも、いずれは直さないといけないと思うわけで。
|
|
|
234 で、予め allocate された領域を利用した placement new を使えば
|
|
|
235 new よりもそれなりに早くなるっぽい。
|
|
|
236 例題として、与えられた回数分 new/delete を繰り返すプログラムと、
|
|
|
237 同じ回数分、placement new したときの速度の比較
|
|
|
238
|
|
|
239 for (int i = 0; i < num; i++) {
|
|
|
240
|
|
|
241 < task = new Task;
|
|
|
242 < task->init(i);
|
|
|
243 < task->printID();
|
|
|
244 < delete task;
|
|
|
245 ---
|
|
|
246 > task = new(buff) Task; // buff = malloc(BUFF_SIZE);
|
|
|
247 > task->init(id);
|
|
|
248 > task->printID(id);
|
|
|
249 }
|
|
56
|
250
|
|
10
|
251 placement new では、delete の必要は無い。
|
|
|
252 その中で新たに allocate してるなら必要かもしれないが。
|
|
|
253 速度比較は以下。no_new が placement new で、ln_new が new/delete 。
|
|
|
254
|
|
|
255 % ./a.out 10 // 10 回
|
|
|
256 no_new: time: 0.012135(msec)
|
|
|
257 ln_new: time: 0.003572(msec)
|
|
|
258
|
|
|
259 % ./a.out 100
|
|
|
260 no_new: time: 0.022453(msec)
|
|
|
261 ln_new: time: 0.018989(msec)
|
|
|
262
|
|
|
263 % ./a.out 1000
|
|
|
264 no_new: time: 0.115277(msec)
|
|
|
265 ln_new: time: 0.136335(msec)
|
|
|
266
|
|
|
267 % ./a.out 10000
|
|
|
268 no_new: time: 1.056156(msec)
|
|
|
269 ln_new: time: 1.322709(msec)
|
|
|
270
|
|
|
271 % ./a.out 100000
|
|
|
272 no_new: time: 10.622221(msec)
|
|
|
273 ln_new: time: 13.362414(msec)
|
|
|
274
|
|
|
275 % ./a.out 1000000
|
|
|
276 no_new: time: 109.436496(msec)
|
|
|
277 ln_new: time: 136.956872(msec)
|
|
|
278
|
|
|
279 10、100 回だと負けてるが、まあ無視しよう(ぇ
|
|
|
280 回数が多くなるにつれて、ほんの少しだが no_new が勝ってる。
|
|
|
281 どうなんだろうね。ちなみに printID を無くすと
|
|
|
282
|
|
|
283 % ./a.out 1000000
|
|
|
284 no_new: time: 0.008512(msec)
|
|
|
285 ln_new: time: 27.100296(msec)
|
|
|
286
|
|
|
287 I/O に左右され過ぎ。まあそんなもんだろうけどさ。
|
