[#352] ruby 1.1a5 released — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

38 messages 1997/09/01
[#353] Re: ruby 1.1a5 released — keiju@... (石塚圭樹 ) 1997/09/01

[#354] Re: ruby 1.1a5 released — matz@... (Yukihiro Matsumoto) 1997/09/01

まつもと ゆきひろです

[#356] Re: methods [Re: ruby 1.1a5 released] — matz@... (Yukihiro Matsumoto) 1997/09/01

まつもと ゆきひろです

[#357] Re: methods [Re: ruby 1.1a5 released] — keiju@... (Keiju ISHITSUKA) 1997/09/01

けいじゅ@日本ラショナルソフトウェアです.

[#359] Re: methods [Re: ruby 1.1a5 released] — matz@... (Yukihiro Matsumoto) 1997/09/02

まつもと ゆきひろです

[#363] Re: methods [Re: ruby 1.1a5 released] — matz@... (Yukihiro Matsumoto) 1997/09/02

まつもと ゆきひろです

[#374] Re: methods [Re: ruby 1.1a5 released] — matz@... (Yukihiro Matsumoto) 1997/09/02

まつもと ゆきひろです

[#376] Re: methods [Re: ruby 1.1a5 released] — keiju@... (Keiju ISHITSUKA) 1997/09/02

けいじゅ@日本ラショナルソフトウェアです.

[#382] Re: methods [Re: ruby 1.1a5 released] — matz@... (Yukihiro Matsumoto) 1997/09/02

まつもと ゆきひろです

[#390] Re: methods [Re: ruby 1.1a5 released] — keiju@... (Keiju ISHITSUKA) 1997/09/03

けいじゅ@日本ラショナルソフトウェアです.

[#391] Re: methods [Re: ruby 1.1a5 released] — matz@... (Yukihiro Matsumoto) 1997/09/03

まつもと ゆきひろです

[#441] How to report a bug — takagi@... (TAKAGI Hiromitsu)

Bus error が出ました。

15 messages 1997/09/09

[#461] [Q] ruby-socket(mswin32) — Masaki Suketa <suke@...>

助田です

27 messages 1997/09/11
[#462] Re: [Q] ruby-socket(mswin32) — matz@... (Yukihiro Matsumoto) 1997/09/11

まつもと ゆきひろです

[#463] Re: [Q] ruby-socket(mswin32) — Masaki Suketa <suke@...> 1997/09/11

助田です

[#464] Re: [Q] ruby-socket(mswin32) — matz@... (Yukihiro Matsumoto) 1997/09/11

まつもと ゆきひろです

[#467] Re: [Q] ruby-socket(mswin32) — WATANABE Hirofumi <watanabe@...> 1997/09/11

わたなべです.

[#594] BUG?(marshal) — Masaki Suketa <suke@...>

以下のプログラムを実行した時に(3)と(4)で出力結果が違います。

17 messages 1997/09/30

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

From: matz@... (Yukihiro Matsumoto)
Date: 1997-09-26 04:03:51 UTC
List: ruby-dev #537
まつもと ゆきひろです

In message "[ruby-dev:536] optimize (Re: Assigne to special variable)"
    on 97/09/26, "EGUCHI Osamu" <eguchi@shizuokanet.or.jp> writes:

|えぐち です。

うーん,えぐちさんってすごい人かも.

|elisp のバイトコードコンパイラなんか、結構すごい最適化を
|かけますよね、elisp に限らず common-lisp 以降の lisp の
|実装は特にチューニングに関しては激しいものがあります。

elispの最適化は調べてません.そんな最適化してました?
Lispに関しては古典的な知識しか無いんです.

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

全てがメソッドで組込みの演算がほとんどないことと,メソッドが
自由に再定義されうる(副作用を持つものに差し替えられているか
も)ので,ピープホールオプティマイズは望み薄です.評価順序の
差し替えや部分式の括り出しすらできないので.

やっぱり高速化には実行系に手を入れるしかないでしょうね.

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

同じ場所で呼ばれるメソッドは大抵同じなので,構文木そのものに
キャッシュとして埋め込むという手法が昔の Smalltalk の実装に
ありました.ただ,これも結局はキャッシュの有効判定のコストな
どがあるので,どれだけ効果が上がるかは自信がないです.昔,
rubyがまだ小さかったころ似たようなことを試した時にはそれほど
劇的には改善しませんでしたが.

|>   * 構文木の再設計(parse.y,node.h,eval.c)
|
|これはたとえば、
|	obj += INTEGER
|を現在は
|	OP_ASGN と INTEGER
|に分解してるのを
|	OP_ASIGN_INTEGER 
|と新しく定義した複合的な単一ノードにして、eval() のトラバースを
|少なくするといった NODE 定義の拡張でしょうか?

いや,もっと大胆なことを考えています.今のrubyは部分式の評価
をrb_eval()の再帰呼出で行っていますが,これを非再帰化すると
言うものです.ただ,そのためにソフトウェアスタックを使う必要
が出たりするとかえって遅くなるかも.まだ実装にかかれる程考え
がまとまっていません.

|魅力的ですが、 gc.c も NODE の解釈をしているのが大変そうですね。

gc.cのNODEの解釈は高速化のためだけですし,知らないノードに対
してもなんとか動くようになっていますので,心配はいりません,
多分.

|> などが考えられます.rubyでは大量にsetjmpを呼んでいるのが明ら
|> かですから,とくに最後のものをいつか実現しようと考えています.
|
|setjmp を使っているところを、他の仕組みで実装すると
|余計遅くなりそうな気がしませんか?

たとえば現在のrubyではwhileなどの単純ループやclass/module定
義などでもsetjmpを使っています.この辺はパーザとの連係で減ら
せるのではないかと考えています.そのためにはrb_evalの非再帰
化が必要そうですけど.

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

いやあ,実は私もです.スレッドなんか良く動いてるなあと自分で
も思うんですけど.

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

rubyの正規表現は遅いですからねえ.librxってperl(4|5)相当の機
能を持たせられましたっけ?

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

これ,具体的にはどんなのでしょう?

                                まつもと ゆきひろ /:|)

In This Thread