結局Rubyは遅いのか遅くないのか

これはすばらしい。
Jewel-mmo開発日記より - Rubyはそんなに遅くない
http://dgames.jp/dan/?permalink&date=20090624_00
実際のゲームに使うようなロジックで、Rubyの実行時間を測っている。
俺はdan5yaさんのこういう性格、というか気質?みたいなところはとても好きだ。


1000個のオブジェクトを移動、画面端での跳ね返り、衝突判定して、60回(1秒分の処理)の時間を測る。
結果が1秒ならギリギリ60fpsということだ。
彼のPCが「Core2 CPU 6400 @ 2.13Ghz」で、だいたい0.18秒。
1000個でそれだけ処理してCPU負荷20%弱なら確かに速い。
別PCでもほぼ同じ結果が書いてあるが、そっちのスペックは不明。
それでは、うちのPen4ではどれぐらいの値になるのだろうか、ということで、同じスクリプトを動かしてみた。
環境はPentium4 2.4GHz、ruby 1.8.7 (2009-06-08 patchlevel 173) [i386-mswin32]だ。

0.421875

ちょwwwおまwww
クロックは高いのに実行時間が倍以上とか!?
無いわー
ついでにruby 1.9.1p0 (2009-01-30 revision 21907) [i386-mswin32]も。

0.21875

傾向はほぼ同じ。
単純にCPUの差がそのまま出ているという事だろう。


俺は昔から、PCで作るゲームはローエンドをターゲットにしてしまう癖がある。
現在のローエンド、数年後を考えてもAtomプロセッサがそこに居座り続ける(だって最新PCとして売ってる)から、そのレベルで考えても、うちのPCの2倍〜2.5倍ぐらいは遅い。
上のスクリプトを動かすだけで60fpsを割るかどうかになる計算だ。
実際にはオブジェクト数の多いタイプのゲームであれば、ターゲットはもっと速いCPUでいいとも思うのだが、遊ぶ側からすると無意味に重いだけに見える。
現在動いているどんなPCでも、2Dゲーム程度ならRubyでも問題なく動くぐらいのレベルになってくれれば理想的だと思う。
理想が高すぎるだけで、いい加減そろそろどこかで割り切る必要があるのかもしれない。


また、そういうことを考えていると、Ruby1.9.1はいい感じで速い。
特にゲームプログラムを動かすことに関して、最適な設計になっているのではないだろうか。
もちろん作ったほうはそんなこと考えてはいなかっただろうけど。
1.9.1ではocraを使う場合に厳しいことになっていて、exe化して配布するには現状ocraしか選択肢がない(exerbダウンロードしても1.9.1コアが入ってない)から、メインは1.8系になってしまう。
惜しいところだ。


ところで、dan5yaさんは記事でこう記している。

上記処理で負荷の1〜2割程度と言うと、 1000個のキャラクターを凝った動かし方にするのは厳しいと思うけど、 数十から数百個レベルなら問題ないんじゃないかな。 描画ライブラリが十分に速ければ。 ライブラリはCで実装できるから十分な高速化が可能だろうし。

描画ライブラリが十分に速ければ。
DXRubyの描画はかなり高速なつもりでいるが、ライブラリを極力シンプルにするために、かなりのコトをRuby側で書くようになっている。
そこが弱点だ。
これを克服するためには、大量に発生するループ処理、描画メソッド呼び出しを、Cのライブラリ内に隠蔽する必要がある。
ついでにありがちな処理も全部Cにまとめてしまえば、凄まじい高速化を実現することができるだろう。
すなわちCによるフレームワーク化だ。
DXRubyは簡単に扱えるのをポイントとしているため、フレームワークにはしていない。
それを作るのは俺にはちょっと難しいのだが。


結局、Rubyは遅いのか、遅くないのか。
思っていること、判断材料は違うかもしれないが、俺の結論もdan5yaさんと同じだ。
Rubyだけでゲームのシステムを組み上げるには厳しい。
Ruby1.9系ならかなり楽になる。
そして、Cによる高速フレームワークを実装しさえすれば、たぶん十分すぎるほど実用になるだろう。
作るのは難しいが、その価値はかなり大きい、ということだ。