LuaJIT 解析 - Qiita
/* A bytecode instruction is about to be executed. Record it. */ void lj_trace_ins(jit_State *J, const BCIns *pc) { /* Note: J->L must already be set. pc is the true bytecode PC here. */ J->pc = pc; J->fn = curr_func(J->L); J->pt = isluafunc(J->fn) ? funcproto(J->fn) : NULL; while (lj_vm_cpcall(J->L, NULL, (void *)J, trace_state) != 0) J->state = LJ_TRACE_ERR; } /* State machine for the trace comp
mrubyのJITの概要 - Qiita
まあ、VMをぶん回すようなプログラムだと、大体5～10倍くらいの速度が出るようです。文字列処理やIOなどCで書かれたライブラリを多用すると速度の差は縮まるでしょう。 内部構造 mrubyのJITはTracing JITです。Tracing JITそのものはググってください。mrubyのVMのバイトコード命令をフェッチして命令毎の処理に分岐するところで制御を乗っ取って実行回数をカウントします。実行回数がある閾値になったら機械語を生成し、次にこの命令を実行したら生成した機械語を呼び出します。 概要をつかむのは名古屋Ruby会議03で発表させてもらったスライドがいいと思います https://www.slideshare.net/miura1729/mrubyjit 内部構造の詳細はこちらを見てください あなとみー おぶ mrubyのJIT (その1) このあと、連続していてその13まであります
mrubyのJITの最適化事典 - Qiita
movの削除 RITE VMで MOVE R2, R0 ADDI R2, 1 のようなコードを考えてます。この場合、正直にR2を代入するのは無駄です。そこで、コード生成時にはR2をR0で設定するコードを生成してしまうのではなく、R2はR0と同じですよという情報だけを持っておきます。そして、ADDI R2, 1でR2を参照するときにR0を参照します。 と、考え方は簡単なんですが、たとえばVMに戻った時どうするのかとかVMから生成コードを呼び出したときどうするのとか罠がいっぱいです。 VMに戻る時はVMのレジスタの整合性を取るようなコードを生成します。また、R0が途中で変わっちゃったらどうするの？という心配もあろうかと思いますが、現在のmrubyのコード生成ではそういうことはないはずです。証明は読者の課題とします。 一方、 ADDI R3, 1 MOVE R2, R3 のようなコードが生成され
YARVのバイトコードをRubyに変換する話 - Qiita
RubyのVMとして知られているYARVのバイトコードをRubyに変換するプログラムを昔書いたことがあるのでその話を書きます。YARVについてはYARV Maniacsを見てもらうのが一番だと思います。 なぜそんなものを? 昔、YARV2LLVMなるものを作っていました。YarvのバイトコードをLLVMに変換するというプログラムです。効率を上げるために型推論をやったりとかしているのですが、詳細は今回の話とは関係ないので詳しくは、Ruby会議で発表した資料でも見てください。 YARV2LLVMではRubyが実行時に提供しているメタプログラミングの機能をコンパイル時に提供するためにマクロ機能を実装しました。マクロはたとえば次のように定義します。 YARV2LLVM::define_macro :attr_reader do |arg| arg.each do |argele| name = a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
