Ruby1.8.xと1.9.1と最適化の行き着く先

なにげにサンプルシューティングをRuby1.9.1で動かしてみたところ、Ruby1.8.7で動かしていた時と最大負荷がかなり近いことに気付いた。
具体的にはYARV採用でVM方式になった1.9.1だが、大雑把に言えば1.8.7で遅かったところを速くしたっつーことで、1.8.7の遅いところに徹底的な対策を施してきているサンプルシューティングは、Ruby1.9.1にしてもほとんど速くならないのだ。
これはなかなか興味深い話である。

アルゴリズムではなく、Ruby言語にフォーカスした最適化を考えてみると、元の動きを変えないという前提なら、大きくわけて以下の2つとなる。
(a)書き換えで速くなる部分
(b)書き換えても速くならない部分
すなわち、(a)はRubyの書き方の中でも特に遅いやり方を選んでしまった部分で、(b)がRubyである限りどうしようもない部分だ。
サンプルシューティングでは全体の最適化はしていないが、ネックになる部分については(a)の部分はほぼ修正した。
(b)のほうはDXRubyExtensionという形で対策した。
この二段構えの最適化により、Ruby1.8.7特有の遅さは克服したと考えてよいようだ。
当然ながら1.9.1で動かしたほうが速いわけだが、言うほど速くならない、というところが論点だ。

拡張ライブラリで高速なプログラムを書けば、いくらでも速くなるじゃん？とか言うのは無し。
あくまでもCで書くのは他でも流用の効く汎用的な部分のみで、ゲームそのもののアルゴリズムはRubyで書くことが前提だ。
それがDXRubyのポリシーであり、それでもRubyが致命的に遅い部分については周辺ライブラリで補足する、というスタイルになっている。現状、流れ的に。
そのスタイルを貫いて、徹底的にネックを解消していったら、1.9.1の速度に近づいてきた。
もちろん1.9.1版でもDXRubyExtensionは使っている。
ということは、1.8.7と1.9.1の差は、俺が解消した部分については大きくなっていたが、そうではない部分についてはあまり無いと考えることができる。
1.9.1は1.9.1で独自の特性があるだろうから、そっちに合わせて最適化すればまだまだ速くなるのだろうが、それはRubyの世界で1.9系がメインになった時にでもやればいいだろう。
ともあれ、努力と工夫次第で1.8.xは1.9.1に近い実行速度が出せる。
負荷が低すぎて比較になってないだけかもしれないが、当初処理落ちまでしていたゲームが比較にならないぐらいまで速くなったのだ。

先のことを考えて行動してるわけではないから、今後の展望などぜんぜんないわけだが、俺の興味の方向性と性格を考えると、やっぱりこんな感じで続いていくのだろう、と思った。
いまのうちからYARVの勉強でもしとこう。