Ruby1.9.0の速度について

http://d.hatena.ne.jp/usagidrop/20071208/1197115477
より：

「これを見る限り、Ruby1.9では以下の項目が遅くなるようだ。」

・ファイルの作成と読み込み
・eval
・正規表現
・例外
・スレッド周り
・インタプリタの起動
・ライブラリの読み込み

下２つは、一旦起動したらずっと動かしているWebアプリケーションの場合、殆ど問題にならないと思います。その上２つは、例外処理を多用してエレガントなコードになっているプログラム（Rubyの場合具体例が浮かびませんが)や、スレッドを頑張ったプログラムは遅くなるかも、と。１番上のファイルＩ／Ｏもスレッド絡みですね。

問題は２点目と３点目です。これらについて互換性維持のため何か総当り的なことをする際にいちいちVMを抜けたり再起動するみたいなことが起こり、どこかでキャッシュミスヒットでメモリからの再ロードが大量に発生した結果か？という風に、元プロセス管理ファームウェア屋としては思ったりします。

while文がループを回り続ける際に遅くないということは、分岐予測が成功している分には上記のようなことは起こらないよう、ちゃんとVMが出来ている、ということなのですが。笹田さんのことですから最近のインテル系CPUの１次キャッシュ（CPUクロックで動作）の容量、それも命令キャッシュとデータキャッシュとのサイズを意識してチューニングしてこられた、と信じておりますが、うーむ、そんなlow levelのことなんか考えるべきじゃないのかな。一度お話伺えばすっきりしそう。

以下は上記記事のフォローで、ささださんとの対話が読めます：
http://d.hatena.ne.jp/usagidrop/20071210/1197222544

なるほど、スレッド化のオーバヘッドをどう平均的に封じ込めるかの苦労、とかなると、上に書いたようなナイーブなことは言ってられないようですね。

usagidropさんが書いておられるように、ファイルＩ／Ｏ時のnative thread をやめるオプションは提供すべき、、でありましょう：

「コンパイル時または起動時にthread modelや正規表現エンジンを指定できる機能があると理想的です。」

これも昔のＣＰＵ屋の発想ですが、ファイルＩ／Ｏを物理層で高速化するテクニックの代表は、インターリーブです。同時アクセスの可能な複数のストレージ領域に隣接アドレスの内容を読み書きするようにして、シーケンシャルなＩ／Ｏの速度ネックを超える手法。

よりハイレベルの制御としてスレッド化がインターリーブにうまくはまるようであれば高速化になるのですが、ずれたら逆に低速化する。

このあたり、on / offじゃなくて、マシン毎に微妙にチューニングできるオプションがあれば良い。というか、そこを実効環境にあわせて自動調整、セルフ・チューニングするプログラムであれば理想的といえそうな気がします。