Mercurial > hg > Papers > 2019 > anatofuz-prosym
annotate Slide/slide.md @ 98:b360b0159390 default tip
update
author | Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 11 Jan 2019 14:08:33 +0900 |
parents | 38ab79fff396 |
children |
rev | line source |
---|---|
84
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
1 title: CbCによるPerl6処理系 |
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
2 author: Takahiro Shimizu, Shinji Kono |
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
3 profile: 琉球大学 |
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
4 lang: Japanese |
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
5 code-engine: coderay |
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
6 |
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
7 |
85 | 8 ## 研究目的 |
90 | 9 - 現在開発されているPerl6の実装にRakudoがあり, RakudoはNQP(Perl6のサブセット)で記述されたPerl6, NQPで記述されたNQPコンパイラ, NQPを解釈するVMで構成されている |
10 - NQPコンパイラはRakudoのVMであるMoarVM用のバイトコードを生成し, MoarVMはこのバイトコードを解釈, 実行する | |
11 - Continuation based C (CbC)という言語は継続を基本とするC言語であり, 言語処理系に応用出来ると考えられる | |
12 - スクリプ言語などは, バイトコードを扱うが, この実行にcae文や, ラベルgotoなどを利用しており, この部分はCbCの機能で書き換える事が可能である | |
13 - 従って, CbC一部用いてPerl6にC処理系であるMoarVMの書き換えを行い, 処理を検討する. | |
14 ![](fig/perl6nqp.svg) | |
15 - (Rakudoの構成図) | |
84
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
16 |
85 | 17 ## Continuation Based C (CbC) |
88 | 18 - Continuation Based C (CbC) はCodeGearを単位として用いたプログラミング言語である. |
85 | 19 - CodeGearはCの通常の関数呼び出しとは異なり,スタックに値を積まず, 次のCodeGearにgoto文によって遷移する. |
20 - CodeGearはCの関数宣言の型名の代わりに`__code`と書く事で宣言出来る. | |
90 | 21 - CodeGearの引数は, 各CodeGearの入出力として利用する. |
85 | 22 |
23 ``` | |
24 extern int printf(const char*,...); | |
90 | 25 |
26 int main (){ | |
27 int data = 0; | |
28 goto cg1(&data); | |
85 | 29 } |
30 __code cg1(int *datap){ | |
90 | 31 (*datap)++; |
85 | 32 goto cg2(datap); |
33 } | |
34 __code cg2(int *datap){ | |
35 (*datap)++; | |
36 printf("%d\n",*datap); | |
37 } | |
38 ``` | |
39 | |
40 ## CbCの現在の実装 | |
41 | |
86 | 42 - CbCは現在3種類の実装がある. |
85 | 43 - gcc (version 9.0.0) |
44 - llvm/clang (version 7.0.0) | |
86 | 45 - micro-c |
85 | 46 |
47 ## 言語処理系の応用 | |
88 | 48 - スクリプト言語処理系は, バイトコードにコンパイルされ, バイトコードをJITを用いてネイティブに変換する |
49 - JITを使わない場合, バイトコードに対応した, case文や, ラベルのテーブルにgotoすることで処理を実行する | |
50 - CbCを言語処理系に応用した場合, バイトコードに対応するCodeGearを生成することが可能である | |
51 - バイトコードに対応したCodeGearは, CodeGearのテーブルを経由することで実行出来る | |
52 - CodeGearに分割することで, 処理を複数の関数で記述する事が出来, ファイル分割などのモジュール化が可能となる | |
85 | 53 |
54 ## Rakudo | |
55 - Rakudoとは現在のPerl6の主力な実装である. | |
56 - 実行環境のVM, Perl6のサブセットであるNQP(NotQuitPerl), NQPで記述されたPerl6(Rakudo)という構成になっている. | |
88 | 57 - コンパイラは, NQPで記述されたPerl6コンパイラ, NQPで記述されたNQPコンパイラ, MoarVMバイトコードを解釈するMoarVMという構成である |
85 | 58 |
59 | |
96 | 60 <img src="fig/tgraph/1.svg" alt="" width="50%" height="50%"/> |
61 | |
62 | |
85 | 63 ## MoarVM |
64 | |
65 - Perl6専用のVMであり, Cで記述されている | |
66 - レジスタマシンとして実装されている. | |
90 | 67 - MoarVMはバイトコードインタプリタを `src/core/interp.c` で定義しており, この中の関数 `MVM_interp_run` でバイトコードに応じた処理を実行する |
85 | 68 |
93 | 69 - マクロDISPATCHで, ラベルgotoかcase文に, バイトコードに対応した処理を行う |
70 - この中の `OP` で宣言されたブロックがそれぞれバイトコードに対応する処理となっている. | |
88 | 71 - この中では `GET_REG` などのマクロを用いてMoarVMのレジスタにアクセスする. |
93 | 72 - `cur_op`は次のバイトコード列が登録されており, マクロ `NEXT` で決められた方法で次のバイトコードに対応した処理に遷移する. |
88 | 73 |
74 ``` | |
75 DISPATCH(NEXT_OP) { | |
76 OP(const_i64): | |
77 GET_REG(cur_op, 0).i64 = MVM_BC_get_I64(cur_op, 2); | |
78 cur_op += 10; | |
79 goto NEXT; | |
80 } | |
81 | |
82 ``` | |
83 | |
95 | 84 ## MVM_BC_get_I64の実装 |
85 | |
86 ``` | |
87 MVM_STATIC_INLINE MVMint64 MVM_BC_get_I64(const MVMuint8 *cur_op, int offset) { | |
88 const MVMuint8 *const where = cur_op + offset; | |
89 #ifdef MVM_CAN_UNALIGNED_INT64 | |
90 return *(MVMint64 *)where; | |
91 #else | |
92 MVMint64 temp; | |
93 memmove(&temp, where, sizeof(MVMint64)); | |
94 return temp; | |
95 #endif | |
96 } | |
97 ``` | |
98 | |
91 | 99 ## MVM_interp_runで使用されているマクロ |
100 | |
94 | 101 ``` |
102 DISPATCH(NEXT_OP) { | |
103 OP(const_i64): | |
104 ``` | |
105 | |
106 - マクロ `DISPATCH` 及び `OP` は次の様に定義している | |
107 | |
108 ``` | |
109 #define OP(name) OP_ ## name | |
110 #define NEXT *LABELS[NEXT_OP] | |
111 ``` | |
112 | |
113 - マクロ`DISPATCH`は, ラベルgotoが利用できる場合は無視される | |
114 - マクロ `OP` が, 対応するバイトコード命令を, ラベル列に変換する | |
115 | |
116 | |
117 ``` | |
118 OP_const_i16: | |
119 OP_const_i32: | |
120 MVM_exception_throw_adhoc(tc, "const_iX NYI"); | |
121 OP_const_i64: | |
122 ``` | |
123 | |
124 ## MVM_interp_runのマクロ | |
93 | 125 |
91 | 126 - MVM_interp_runではマクロを利用してMoarVMの環境などにアクセスしている |
127 - 頻出するマクロに `GET_REG` があり, 次のような使い方をする | |
128 | |
129 ``` | |
130 OP(const_i64): | |
131 GET_REG(cur_op, 0).i64 = MVM_BC_get_I64(cur_op, 2); | |
132 cur_op += 10; | |
133 ``` | |
134 | |
135 | |
93 | 136 - `GET_REG`はバイトコードに埋められた数値を利用して, レジスタ情報を取得/設定などをする |
137 - `GET_REG`は次の様に展開される | |
138 | |
139 ``` | |
140 reg_base[*((MVMuint16 *)(cur_op + 0))].i64 = MVM_BC_get_I64(cur_op, 2); | |
91 | 141 ``` |
142 | |
93 | 143 - `reg_base` はMoarVMの現在のフレームのレジスタ情報が保存されたポインタであり, MVM_interp_runではローカル変数として利用している |
91 | 144 |
93 | 145 ## MVM_interp_runで使用されているマクロ |
88 | 146 |
93 | 147 - 次のバイトコード命令に遷移するマクロ `NEXT` は, ラベルgotoが使用可能な場合次の様に記述されている |
148 - `NEXT`自体はラベルテーブルにアクセスし, ラベルを取り出す | |
149 - 次のバイトコードを取り出すのは, `NEXT_OP` というマクロが担っている | |
85 | 150 |
151 ``` | |
152 #define NEXT_OP (op = *(MVMuint16 *)(cur_op), cur_op += 2, op) | |
93 | 153 #define NEXT *LABELS[NEXT_OP] |
85 | 154 |
93 | 155 ``` |
156 - マクロ `NEXT` は次の様に展開される | |
157 | |
85 | 158 ``` |
93 | 159 goto *LABELS[(op = *(MVMuint16 *)(cur_op), cur_op += 2, op)]; |
160 ``` | |
161 | |
85 | 162 |
94 | 163 ## MVM_interp_runのラベルテーブル |
85 | 164 |
165 - ラベル遷移を利用する場合は配列`LABELS`にアクセスし, ラベル情報を取得する | |
166 | |
167 ``` | |
168 static const void * const LABELS[] = { | |
169 &&OP_no_op, | |
170 &&OP_const_i8, | |
171 &&OP_const_i16, | |
172 &&OP_const_i32, | |
173 &&OP_const_i64, | |
174 &&OP_const_n32, | |
175 &&OP_const_n64, | |
176 &&OP_const_s, | |
177 &&OP_set, | |
178 &&OP_extend_u8, | |
179 &&OP_extend_u16, | |
180 &&OP_extend_u32, | |
181 &&OP_extend_i8, | |
182 &&OP_extend_i16, | |
183 ``` | |
184 | |
185 | |
186 ## MVM_interp_run | |
187 | |
188 - Cの実装の場合, switch文に展開される可能性がある為, 命令ディスパッチが書かれているCソース・ファイルの指定の場所にのみ処理を記述せざるを得ない | |
189 - その為, 1ファイルあたりの記述量が膨大になり, 命令のモジュール化ができない | |
190 - Threaded Codeの実装を考えた場合, この命令に対応して大幅に処理系の実装を変更する必要がある. | |
191 - デバッグ時には今どの命令を実行しているか, ラベルテーブルを利用して参照せざるを得ず, 手間がかかる. | |
192 | |
193 | |
194 | |
195 ## CbCMoarVMのバイトコードディスパッチ | |
196 | |
95 | 197 - CbCをMoarVMに適応すると, ラベルなどで制御していた命令に対応する処理をCodeGearで記述する事が可能である |
198 - オリジナルでは, マクロ `NEXT` が担当していた, 次のバイトコードへの移動は, NEXT相当のCodeGear `cbc_next`で処理を行う | |
199 - CodeGearの入出力として, MoarVMなどの情報をまとめた構造体を利用する | |
84
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
200 |
85 | 201 ``` |
95 | 202 __code cbc_next(INTERP i){ |
203 __code (*c)(INTERP) | |
204 c = CODES[(i->op = *(MVMuint16 *)(i->cur_op), i->cur_op += 2, i->op)]; // c = NEXT(i) | |
205 goto c(i); | |
206 } | |
207 | |
208 __code cbc_const_i64(INTERP i){ | |
209 GET_REG(i->cur_op, 0,i).i64 = MVM_BC_get_I64(i->cur_op, 2); | |
210 i->cur_op += 10; | |
211 goto cbc_next(i); | |
212 } | |
213 | |
85 | 214 ``` |
215 | |
216 ## CodeGearの入出力インターフェイス | |
217 | |
218 - MoarVMではレジスタの集合や命令列などをMVM_interp_runのローカル変数として利用し, 各命令実行箇所で参照している | |
219 - CodeGearに書き換えた場合, このローカル変数にはアクセスする事が不可能となる. | |
220 - その為, 入出力としてMoarVMの情報をまとめた構造体interpのポインタであるINTERPを受け渡し, これを利用してアクセスする | |
221 | |
222 | |
223 ``` | |
224 typedef struct interp { | |
225 MVMuint16 op; | |
226 MVMuint8 *cur_op; | |
227 MVMuint8 *bytecode_start; | |
228 MVMRegister *reg_base; | |
229 /* Points to the current compilation unit | |
230 . */ | |
231 MVMCompUnit *cu; | |
232 /* The current call site we’re | |
233 constructing. */ | |
234 MVMCallsite *cur_callsite; | |
235 MVMThreadContext *tc; | |
236 } INTER,*INTERP; | |
237 ``` | |
238 | |
95 | 239 ## CbCMoarVMのCodeGearテーブル |
85 | 240 |
95 | 241 - CodeGearテーブルは引数としてINTERを受け取るCodeGearの配列として定義する |
85 | 242 |
243 | |
244 ``` | |
95 | 245 __code (* CODES[])(INTERP) = { |
246 cbc_no_op, | |
247 cbc_const_i8, | |
248 cbc_const_i16, | |
249 cbc_const_i32, | |
250 cbc_const_i64, | |
251 cbc_const_n32, | |
252 cbc_const_n64, | |
253 cbc_const_s, | |
254 cbc_set, | |
255 cbc_extend_u8, | |
256 cbc_extend_u16, | |
257 ``` | |
90 | 258 |
85 | 259 |
88 | 260 ## NQP |
261 - Perl6の機能を制約したプログラミング言語であり, Perl6はNQPで記述されている | |
262 - その為Perl6処理系は, NQPの動作を目的に実装することでPerl6の動作が可能となる | |
263 - NQPコンパイラ自身もNQPで記述されている | |
264 - Perl6と違い, 変数の宣言を `:=` を利用した束縛で行う, `++` 演算子が使用できないなどの違いがある | |
265 - nqpのオペコードを利用する際に,型を指定する事が可能である | |
266 | |
267 ``` | |
268 sub add_test(int $n) { | |
269 my $sum := 0; | |
270 while nqp::isgt_i($n,1) { | |
271 $sum := nqp::add_i($sum,$n); | |
272 $n := nqp::sub_i($n,1); | |
273 } | |
274 return $sum; | |
275 } | |
276 | |
277 say(add_test(10)); | |
278 ``` | |
279 | |
90 | 280 ## NQPのバイトコード |
281 | |
282 - NQPはMoarVMのバイトコードにコンパイルし, バイトコードをファイルに保存することが可能である | |
283 - MoarVMのバイトコードは, アセンブリの様にダンプする事が可能である | |
284 - 実際に先程のコードをバイトコードにコンパイルし, 対応するバイトコードをダンプすると次の様に表示される | |
285 | |
286 | |
287 ``` | |
288 annotation: hoge.nqp:3 | |
289 label_1: | |
290 00007 const_i64_16 loc_2_int, 1 | |
291 00008 gt_i loc_2_int, loc_0_int, loc_2_int | |
292 00009 unless_i loc_2_int, label_2(00022) | |
293 00010 osrpoint | |
294 annotation: hoge.nqp:4 | |
295 00011 decont loc_3_obj, loc_1_obj | |
296 00012 smrt_numify loc_4_num, loc_3_obj | |
297 00013 coerce_ni loc_5_int, loc_4_num | |
298 00014 add_i loc_5_int, loc_5_int, loc_0_int | |
299 00015 hllboxtype_i loc_3_obj | |
300 00016 box_i loc_3_obj, loc_5_int, loc_3_obj | |
301 00017 set loc_1_obj, loc_3_obj | |
302 annotation: hoge.nqp:5 | |
303 00018 const_i64_16 loc_5_int, 1 | |
304 00019 sub_i loc_5_int, loc_0_int, loc_5_int | |
305 00020 set loc_0_int, loc_5_int | |
306 00021 goto label_1(00007) | |
307 ``` | |
308 | |
96 | 309 ## NQPのバイトコードとCbC |
310 | |
311 - NQPが生成したMoarVMバイトコードは確実に次に実行される命令がある箇所が複数存在する | |
312 - 静的にCのソースファイルに, NQPが生成したバイトコードと対応するCbCのCodeGearの実行を書くことで決定的に命令を実行可能でえある. | |
313 | |
314 ## CbCMoarVMの利点 | |
315 | |
316 - バイトコードインタプリタの箇所をモジュール化する事が可能となり, CodeGearの再利用性や記述生が高まる | |
317 - デバッグ時にラベルではなくCodeGearにbreakpointを設定可能となり,デバッグが安易となる | |
318 | |
319 ## CbCMoarVMの欠点 | |
320 | |
321 - CbCコンパイラがバグを発生させやすく, 意図しない挙動を示す事がある | |
322 - CbCコンパイラ自体のバグも存在する | |
323 - MoarVMのオリジナルの更新頻度が高い為, 追従していく必要がある | |
324 - CodeGear側からCに戻る際に手順が複雑となる | |
325 - CodeGearを単位として用いる事で複雑なプログラミングが要求される. | |
326 | |
327 | |
90 | 328 |
85 | 329 ## MoarVMのデバッグ手法 |
330 | |
331 - MoarVMはバイトコードをランダムに生成する仕様となっている | |
332 - 一旦moarvmバイトコードとして出力したファイルを実行する場合は同じ処理内容となっている | |
333 - そのため, MoarVMのデバッグは同じバイトコードを入力として与え, オリジナルのMoarVMと並列してgdbを用いてトレースを行う. | |
334 - この際, 実行するバイトコードの数が膨大となるので, scriptコマンドを用いて実行するバイトコードの番号を吐き出し, ログファイルを用いて比較する. | |
335 | |
336 ## MoarVMのデバッグ時のbreak point | |
337 | |
338 - CbC側では次のオペコードの遷移は `cbc_next` というCodeGearで行う | |
339 - CodeGearは関数として扱える為, これに直接break pointを設定する | |
84
6c69fdd1716c
add slide.md (template...)
Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
340 |
85 | 341 ``` |
342 (gdb) b cbc_next | |
96 | 343 Breakpoint 2 at 0x7ffff7560288: file src/core/cbc-interp.cbc, line 61. |
85 | 344 (gdb) command 2 |
96 | 345 Type commands for breakpoint(s) 2, one per line. |
85 | 346 End with a line saying just "end". |
347 >p CODES[*(MVMuint16 *)i->cur_op] | |
348 >p *(MVMuint16 *)i->cur_op | |
349 >c | |
350 >end | |
351 ``` | |
352 - オリジナルの場合マクロである為, dummy関数をマクロに記述し, この関数にbreakpointを設定する | |
353 | |
354 ``` | |
96 | 355 dalmore gdb --args ../../MoarVM_Original/MoarVM/moar --libpath=src/vm/moar/stage0 gen/moar/stage1/nqp |
85 | 356 (gdb) b dummy |
357 Function "dummy" not defined. | |
96 | 358 Make breakpoint pending on future shared library load? (y or [n]) y |
85 | 359 Breakpoint 1 (dummy) pending. |
360 (gdb) command 1 | |
96 | 361 Type commands for breakpoint(s) 1, one per line. |
85 | 362 End with a line saying just "end". |
363 >up | |
364 >p *(MVMuint16 *)(cur_op) | |
365 >c | |
366 >end | |
96 | 367 |
85 | 368 ``` |
369 | |
370 ## MoarVMのトレース | |
371 | |
372 - トレース時には次の様なデバッグ情報の表示を利用する | |
373 - デバッガに, breakpointで停止した際のcur_opの値を表示する様に設定する. | |
374 | |
375 ``` | |
96 | 376 Breakpoint 1, dummy () at src/core/interp.c:46 |
377 46 } | |
378 #1 0x00007ffff75608fe in MVM_interp_run (tc=0x604a20, | |
379 initial_invoke=0x7ffff76c7168 <toplevel_initial_invoke>, invoke_data=0x67ff10) | |
85 | 380 at src/core/interp.c:119 |
96 | 381 119 goto NEXT; |
85 | 382 $1 = 159 |
96 | 383 |
384 Breakpoint 1, dummy () at src/core/interp.c:46 | |
385 46 } | |
386 #1 0x00007ffff75689da in MVM_interp_run (tc=0x604a20, | |
387 initial_invoke=0x7ffff76c7168 <toplevel_initial_invoke>, invoke_data=0x67ff10) | |
85 | 388 at src/core/interp.c:1169 |
96 | 389 1169 goto NEXT; |
85 | 390 $2 = 162 |
391 ``` | |
88 | 392 |
96 | 393 ## CbCMoarVMのデバッグ |
394 | |
395 ``` | |
396 Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61 | |
397 61 goto NEXT(i); | |
398 $1 = (void (*)(INTERP)) 0x7ffff7566f53 <cbc_takeclosure> | |
399 $2 = 162 | |
400 | |
401 Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61 | |
402 61 goto NEXT(i); | |
403 $3 = (void (*)(INTERP)) 0x7ffff7565f86 <cbc_checkarity> | |
404 $4 = 140 | |
405 | |
406 Breakpoint 2, cbc_next (i=0x7fffffffdc30) at src/core/cbc-interp.cbc:61 | |
407 61 goto NEXT(i); | |
408 $5 = (void (*)(INTERP)) 0x7ffff7579d06 <cbc_paramnamesused> | |
409 $6 = 558 | |
410 | |
411 | |
412 ``` | |
88 | 413 |
85 | 414 ## MoarVMのデバッグ |
415 | |
416 - cur_opのみをPerlスクリプトなどを用いて抜き出し, 並列にログを取得したオリジナルと差分を図る | |
417 - この際に差異が発生したオペコードを確認し, その前の状態で確認していく | |
418 | |
419 ``` | |
420 131 : 131 | |
421 139 : 139 | |
422 140 : 140 | |
423 144 : 144 | |
424 558 : 558 | |
425 391 : 391 | |
426 749 : 749 | |
427 53 : 53 | |
428 *54 : 8 | |
429 ``` | |
90 | 430 |
85 | 431 ## 現在のCbCMoarVM |
432 | |
433 - 現在はNQP, Rakudoのセルフビルドが達成でき, オリジナルと同等のテスト達成率を持っている | |
434 - moarの起動時のオプションとして `--cbc` を与えることによりCbCで動き, そうでない場合は通常のCで記述された箇所で実行される | |
90 | 435 - Perl6の実行バイナリperl6, NQPの実行バイナリnqp は, それぞれmoarを起動するシェルスクリプトである為, `--cbc` オプションをシェルスクリプト内に書き加えることで, Perl6, NQPがそれぞれCbCで起動する |
436 | |
437 ``` | |
438 #!/bin/sh | |
439 exec /mnt/dalmore-home/one/src/Perl6/Optimize/llvm/build_perl6/bin/moar --cbc \ | |
440 --libpath=/mnt/dalmore-home/one/src/Perl6/Optimize/llvm/build_perl6/share/nqp/lib \ | |
441 /mnt/dalmore-home/one/src/Perl6/Optimize/llvm/build_perl6/share/nqp/lib/nqp.moarvm "$@" | |
442 ``` | |
85 | 443 |
88 | 444 ## ThreadedCodeの実装 |
445 | |
446 - MoarVM内のオペコードに対応する処理が分離出来たことにより, オペコードに該当するCodeGearを書き連ねることによってThreadedCodeが実装可能となる | |
447 | |
448 | |
85 | 449 ## CbCMoarVMと通常のMoarVMの比較 |
450 | |
451 - CbCMoarVMと通常のMoarVMの速度比較を行った | |
88 | 452 - 対象として, 単純なループで数値をインクリメントする例題と, フィボナッチ数列を求める例題を選択した |
453 - NQPで実装した場合とPerl6で実装した場合の速度を計測した | |
85 | 454 |
455 ``` | |
456 #! nqp | |
88 | 457 |
458 my $count := 100_000_000; | |
85 | 459 |
460 my $i := 0; | |
88 | 461 |
462 while ++$i <= $count { | |
85 | 463 } |
464 ``` | |
465 | |
466 ``` | |
88 | 467 #! nqp |
468 | |
469 sub fib($n) { | |
470 $n < 2 ?? $n !! fib($n-1) + fib($n - 2); | |
471 } | |
85 | 472 |
96 | 473 my $N := 30; |
85 | 474 |
88 | 475 my $z := fib($N); |
476 | |
477 say("fib($N) = " ~ fib($N)); | |
85 | 478 |
479 ``` | |
95 | 480 ## フィボナッチの例題 |
88 | 481 |
96 | 482 - オリジナル |
483 - 1.379 sec | |
484 - 1.350 sec | |
485 - 1.346 sec | |
486 - CbCMoarVM | |
487 - 1.636 sec | |
488 - 1.804 sec | |
489 - 1.787 sec | |
88 | 490 - フィボナッチの例題ではCbCMoarVMが劣る結果となった |
491 | |
492 | |
493 ## 単純ループ | |
494 | |
495 - オリジナル | |
496 - 7.499 sec | |
497 - 7.844 sec | |
96 | 498 - 6.746 sec |
88 | 499 - CbCMoarVM |
500 - 6.135 sec | |
501 - 6.362 sec | |
502 - 6.074 sec | |
503 | |
504 - 単純ループではCbCMoarVMの方が高速に動作する場合もある | |
505 | |
506 | |
95 | 507 ## 基本ブロックとCodeGear |
508 | |
509 - コンパイラなどでは, 関数あるいはループの先頭から, 別の関数呼び出し, あるいはジャンプするまでの間のコードを基本ブロックと呼ぶ | |
510 - 基本ブロックは入力に影響を受けず, 基本ブロックが決定したタイミングである決定的な処理を行う | |
96 | 511 - 予め実行する基本ブロックが確定していれば, その部分のみ抜き出してコンパイルする事が可能である |
512 - CbCのCodeGearは, この基本ブロックとみなす事が可能である | |
513 - その為, NQPの例題の様に, 予め実行する基本ブロックが確定すれば, その部分の処理が可能となる | |
514 - これを行うことで, CbCを用いてMoarVMのThreadedCode実装が可能となる | |
515 | |
516 ``` | |
517 __code cbc_const_i64(INTERP i,__code cbc_next(INTERP i)){ | |
518 GET_REG(i->cur_op, 0,i).i64 = MVM_BC_get_I64(i->cur_op, 2); | |
519 i->cur_op += 10; | |
520 goto cbc_next(i); | |
521 } | |
522 | |
523 goto cbc_const_i64_16(i,cbc_gt_i_01); | |
524 | |
525 __code cbc_gt_i_01(INTERP i){ | |
526 goto cbc_gt_i(i,cbc_unless_i_01); | |
527 } | |
528 | |
529 __code cbc_unless_i_01(INTERP i,cbc_osrpoint_01){ | |
530 goto cbc_unless_i(i,cbc_osrpoint_01); | |
531 } | |
532 ``` | |
95 | 533 |
88 | 534 |
535 ## まとめと今後の課題 | |
536 - 継続と基本としたC言語 Continuation Based Cを用いてPerl6の処理系の一部を書き直した | |
537 - CbCの持つCodeGearによって, 本来はモジュール化出来ない箇所をモジュール化する事が出来た | |
538 - MoarVMの速度改善にはThreadedCodeが期待でき, CodeGearベースの命令ディスパッチとThreadedCodeは相性が良いと考えられる | |
539 - 今後は実行するバイトコードによりThreadedCode箇所と通常の配列を読み取り, 次のCodeGearを計算する処理を両立させていく | |
540 |