[ruby-dev:536] optimize (Re: Assigne to special variable)

えぐち です。

----------
> 
> まつもと ゆきひろです
> 
> In message "[ruby-dev:522] Re: Assigne to special variable"
>     on 97/09/25, "EGUCHI Osamu" <[e-mail]> writes:
> 
> |えぐち です。
> 
> |どうも実行時に言語仕様の一部が書き換わってるような感じで
> |最適化って余地が殆どないような気がします。
> |バイトコード？最適化の議論って今までされたことあるんでしょうか？
> 
> rubyに限らないですが，動的な性質を持つ言語ではコンパイラの教
> 科書に良くあるいわゆる最適化をほとんど適用できません．最適化
> は私が学生時代所属していた研究室の重要なテーマでもありました
> ので，いろいろ考えましたが，やっぱり無理のようです．
> # Lispとかもそうでしょうね．

その道を極めた方に言うのは、いかにも『釈迦に説法』ですが、、

elisp のバイトコードコンパイラなんか、結構すごい最適化を
かけますよね、elisp に限らず common-lisp 以降の lisp の
実装は特にチューニングに関しては激しいものがあります。
でも ruby はランタイムにコンパイルするので、あまり大規模な
コンパイル時のオプティマイズは結果として速度低下を招くのが
つらいところです。

と言うことで、いわゆるピープホールオプティマイズと
ランタイムエンジン部分のチューニングが ruby では効果的では？

> rubyにおいて実行速度を改善する余地は
> 
>   * メソッドキャッシュの改善(eval.c)

中規模なアプリケーションでなら、0x200 エントリのメソッドキャッシュ
でも（gcov で見ると）かなりヒットしているように思えます。
むしろエントリーを増やすより、再定義などでクリアされるない様に
したいところですが、メソッドとオブジェクトの結合が動的なので
ほとんど不可能に近いですね。

>   * 構文木の再設計(parse.y,node.h,eval.c)

これはたとえば、
	obj += INTEGER
を現在は
	OP_ASGN と INTEGER
に分解してるのを
	OP_ASIGN_INTEGER 
と新しく定義した複合的な単一ノードにして、eval() のトラバースを
少なくするといった NODE 定義の拡張でしょうか？
魅力的ですが、 gc.c も NODE の解釈をしているのが大変そうですね。

他にも、
	obj = obj + n
のパターンから
	obj += n
を生成するとかはオーバーホールなしに、parse.y だけで解決しそうです。

>   * setjmpの削減(eval.c)
> 
> などが考えられます．rubyでは大量にsetjmpを呼んでいるのが明ら
> かですから，とくに最後のものをいつか実現しようと考えています．

setjmp を使っているところを、他の仕組みで実装すると
余計遅くなりそうな気がしませんか？
いまのイーバリェータってパーサに比べて手を入れる余地が
あまりないような気がします。

私が Thread 関係のコードに恐れをなしている事が一番の理由なんですが、
(GC と Thread は私の理解を超えてます :-p)

＃
それから、/RE/ のコンパイルの部分を新しい librx に差し替えると
速くなるかもしれないです。
、、今の GPL な regex をスクラッチから書き直すって ToDo にあったやうな、、

まったく別の場所では、Bignum の四則や比較といった重いところを、
「if 文の算術式化」などで、少しチューニング出来そうな気がします。

	えぐち