From: EGUCHI Osamu Date: 1997-09-26T12:42:00+09:00 Subject: [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" 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 文の算術式化」などで、少しチューニング出来そうな気がします。 えぐち