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まであります
VMに手を加えずRubyを高速化するJITコンパイラ「YARV-MJIT」の話 - k0kubun's blog
先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回
mrubyのJITにおけるメソッド再定義の対処方法 - Qiita
Rubyはメソッドの再定義が出来るのですが、これがJITコンパイラを作るときに問題になります。メソッドそのものを再定義しなければならないのはもちろん、各所に散らばっているそのメソッドを呼び出している元も書き換えなければならないからです。さもなければ、再定義されているかを毎回チェックする必要があり、大幅に速度が落ちます。 mrubyのJITではコードの自己書き換えを駆使することで速度を落とさず再定義に対処しています。ただし、メモリ効率が悪いので、頻繁な書き換えには向きません。 mrubyのJITではこんな感じで生成コードを管理しています。この場合は、メソッドfooの場合です。 entry tableってのがあって、RITE VMの命令毎に対応する機械語コードのアドレスが入っています。Tracing JITなのでプログラムが全て機械語になっている保証はないですので、これを見て対応する機械語命令
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Home
