お盆休みの一部を利用して、mruby-prpfiler(https://github.com/miura1729/mruby-profiler)を復活させました。 mruby-profilerって何? mruby-profilerはVMの命令ごとに実行時間を数えていて、rubyのソースコードやVMの命令レベルで実行時間を表示してくれるというものです。フィボナッチを実行すると、こんな感じの出力が最後に出ます。 0000 0.00000 # Fib 39 0001 0.00000 0002 0.00000 def fib n 0003 4119.25760 return n if n < 2 204668309 586.53534 MOVE 204668309 666.29443 LOADI 204668309 927.08844 LT 204668309 1377.01244 JMPNOT

@matsumotoryさんの面白い記事　「インフラエンジニアの僕がキーボードのすぐ隣に置いておきたい本」　http://blog.matsumoto-r.jp/?p=4279　をぱくって記事を書いてみました。 手元に置いておきたいが、置いているわけじゃない5冊 Common Lisp　第二版　(http://www.amazon.co.jp/dp/4320025881) 一見、無味乾燥ですが面白い本です。「処理系の注」と「論理的根拠」のところをしっかり読みましょう。世の中には深く深くものを考える人がいるのだなと分かります。 初めてのRuby (http://www.amazon.co.jp/dp/4873113679) プログラミング言語を使えるようになるだけならいろんな本もあるし、ネットでただで手に入れることもできるわけですが、言語のバックグラウンドにある思想も含めた優れた解説はなかな

とってもお久しぶりです。ずいぶん間が空いてしまいましたが、新たな機能のプリミティブのインライン化が実装できたので再開したいと思います。あなとみー　おぶ　mrubyのJIT　の開始当時オリジナルmrubyの数割速いとか遅くなるとか言っていましたが、現在大体のベンチマークでmrubyの2〜4倍の速度が出ます。その秘密が今回紹介するプリミティブのインライン化です。 Rubyはかなり基本的な機能もすべてメソッド呼び出しで実装されています。これは、必要に応じて動作をカスタマイズしたりして柔軟性をもたらしますが、速度的には大きなハンディになります。とくに、mrubyはメソッド呼び出しのオーバーヘッドが大きいので問題になります。 そこで、mrubyのJITでは良く使うメソッドについてはインライン化して速度を稼ぐようにしました。 インライン化を支えるコード 具体的なコードを見てみましょう。 これは、arr

追記 LuaJITの作者Mike Pall氏より、twitterで次のようなアドバイスをいただきました。 1. No compiler is allowed to make this optimization. Floating-point arithmetic ist NOT associative. 2. Please use 'local' functions when publishing Lua benchmarks. 3. Please use the current version of LuaJIT. 訳(かなり怪しい) 1．このような最適化出来るコンパイラは無いよ。浮動小数点数の算術命令は結合的じゃないから 2. Luaのベンチマークを取るなら局所関数を使ってください 3. 最新バージョンのLuaJITを使ってください そういうわけで、ベンチマークを取り直します。 ベンチ

お久しぶりです。ここんとこしばらくProcオブジェクトのサポートを作りこんでました。これが無いとイテレータとかみんなVMに戻ってしまって性能が上がらないのです。実はProcオブジェクトをサポートしてもあまり性能が上がらなかったのですが…。 で、この作業ですごくとりにくいバグがいっぱい出て数カ月デバッグ三昧という感じでした。おかげてうまく動くようになると却って落ち着かないという状態なのですが、それはそれとしてそのデバッグで作ったツールを紹介したいと思います。全国に31名くらいいると思われるmrubyでJITコンパイラを作っている人たちに参考になれば幸いです。 デバッグしていて困るのはどの命令を実行していた時にバグったのかが分からないことです。vm.cで実行していた場合は命令毎に処理が分かれているのでまだいいのですが、ネイティブコードでバグった場合(例えばセグフォしたばあいとか)、mrubyの

前回の1.10001・・・は最初に証明された超越数の10倍でした。 私が積読してあることで名高い「人月の神話」には、つぎのようなくだりがあります。 私にフローチャートを見せられて、テーブルを見せないとしたら、私はずっと煙に巻かれたままになるだろう。逆にテーブルが見せてもらえるなら、フローチャートは大抵必要なくなる そういうことで、mrubyのJITの解説第二回目はデータ構造です。 よく言われることですが、mrubyには大域変数が無く代わりにstate構造体(mrb_state)を定義してそのポインタをほぼすべての関数に引数として渡すようにしています。このような構造はVMを複数作れるとか嬉しいことが多いのですが、mrubyのJITに関しても恩恵にあずかっています。この恩恵については後で説明しますが(伏線回収できるかな？どきどき)、mrb_stateにちゃっかりJITで使う変数も忍ばせています

謝辞を忘れていました。mrubyのJITはXbyak(http://homepage1.nifty.com/herumi/soft/xbyak.html)を使わせてもらっています。今まで、C言語の生成、LLVM、Rubyで書いた自作アセンブラなどでコンパイラを使っていましたが、Xbyakは一番使いやすいです。 某出版会(http://tatsu-zine.com/books/llvm)には大変申し訳ないのですが、個人的には速度とか移植性を考えないコンパイラならLLVMよりXbyakの方がお勧めです。移植性とか最適化したいとかの話になると途端にXbyakはハードルが上がりますが… 作者のherumiさんにはmrubyのJITを試し戴いてデバッグの協力まで戴きました。 https://github.com/miura1729/mruby/issues/1 本当にありがとうございます。 ちなみに

ふと思い立ってものすごく影の薄いmrubyのJITの内部構造を説明することにしました。mrubyのJITは正式名称がないというとてもかわいそうなmrubyのフォークですが、オリジナルのmrubyの1〜3割(倍じゃないのに注意)速いようです。ここにあります、 https://github.com/miura1729/mruby さて、mrubyのJITはTracing JITなるものを使っています。第一回目はTracing JITの説明をしたいと思います。コードの解説はしないので、そういうのが読みたい人はTwrtter (@miura1729)かコメントで続きはよとつっついてください。 Tracing JITは今やLuaJIT, Pypyをはじめとするいろんな処理系で使われていますが、あまり解説記事はないようです。ただ、http://dodgson.org/omo/t/?date=20080