2009-07-03
yarv2llvmの近況(自分用のメモ)
インライン展開処理にバグがあって--inline-blockが実は動いていなかったのですが、動くようにしました。でもまだ、バグがあるようです。bm_so_mandelbrotの実行結果がおかしくなります。--inline-blockをつけると、Fixnum#times, Array#each, Range#eachなどの組み込みのイテレータについては、ブロックもループ処理も1つの関数の中に展開されます。効果は速くなるものも遅くなるものもあるという感じです。
ブロック内のbreak, continueなどを実装し始めました。ブロック内のbreakはthrow命令にコンパイルされて例外処理(スタックのunwind)が必要になるのですが、ブロックをインライン展開することで単なるjmp命令にコンパイルすることができます。
また本物の例外処理もLinuxではinvoke/unwind命令はDwarf3の情報を使った0-costのものが生成されることを確認したので、そろそろサポートしようかなと思います。
yarv2llvmの実行速度は今のところ、ランタイム(GCやIOなど)に負荷を掛けるものじゃなければ、Ruby 1.9の10倍くらいかなという印象です。The Computer Language Benchmarks Game(http://shootout.alioth.debian.org/)の結果を見るとCなどはRuby 1.9の100倍くらいのようです。
yarv2llvmでは無理ですが、Cと同等のパフォーマンスが出せるRubyが開発できる可能性について考えています。少なくともCコンパイラの開発と同じくらいのリソースは必要だと思います。やっぱりbignumがネックになりそうですが、オーバーフロー割り込みをサポートしているCPUならあるいは・・・、と思いますが。
追記
yarv2llvmはbignumをサポートしてないです.もしサポートすると整数演算の前後にbit演算の条件判定が入るので劇的な速度低下は間違いないと思います。オーバーフローを低コストで見つける方法ないかなー。bignumかのチェックは初めは入れなくてbignumが生成されたらそのbignumが到達できる演算にbignumかのチェックを入れるように再コンパイルするような戦略にすると良いのかなー。
- 23 http://www.rubyist.net/~kazu/samidare/
- 3 http://a.hatena.ne.jp/asip/
- 3 http://reader.livedoor.com/reader/
- 2 http://a.hatena.ne.jp/Ddtana/
- 2 http://llvmruby.org/wordpress-llvmruby/
- 2 http://www.google.co.jp/search?hl=ja&safe=off&rlz=1T4GGLL_jaJP317JP317&q=+site:d.hatena.ne.jp+jemalloc+arena
- 2 http://www.google.com/search?hl=ja&client=safari&rls=ja-jp&q=ruby+tk+アニメーション&btnG=検索&lr=
- 2 http://www.google.com/search?source=ig&hl=ja&rlz=1G1GGLQ_JAJP258&=&q=谷山浩子のオールナイトニッポン+ニコニコ&btnG=Google+%
- 1 http://d.hatena.ne.jp/keyworddiarymobile/Ruby?date=20090703
- 1 http://d.hatena.ne.jp/kwatch/20080304/1204646782
LLVMだとキャリーフラグを使うことができるからオーバーフローチェックはブランチ命令一発になり、分岐予測が決まればそんなにペナルティ無いかもしれないです。
そういえば、ナイーブにBignum対応するとタグ無しのFixnumが使えなくなりますね。これはうれしくないからBignumが発生してから再コンパイルしようとすると、フレームのタグ無しFixnumを箱に入れて回らないといけない。結構大変そうです。