MAEDA Atusi <maeda-yarv atusi.org> wrote :
    [ [yarv-dev:207] Re: return from orphan Proc object ]
    at 16 Sep 2004 17:19:46 +0900

　ささだです．

> ささださんが意図している最適化は、
> ・呼び出し側がProc.newを使わず { ... } を渡し、
> ・かつ、呼び出される側が暗黙の引数で受けとった時に、
> 一人前のProcを割り当てずに軽いもの(Lispの世界だとeasy closureとか呼ん
> だりする)だけ作って済まそうというものだと思います。

　はい．そのとおりです．Ruby の場合，一般的には easy closure
ばかりが利用されるんじゃないかなー，と想像してます．


> 呼び出される側は、FullProcとEasyProcを区別せずにyieldできるのでしょう
> か?  もし区別が必要だとすると、iterator側では両方のコードを用意するの
> でしょうか、それともどちらかにcanonicalizeするのでしょうか?

　区別が必要なのは，yieldするときで，その yield 1命令だけが，
頑張ってそれぞれの処理を振り分ければ問題ないと考えています．
特に，その振り分け自体が難しいとも思えません．

Insn yield{
  block = GET_BLOCK();

  if(CLASS_OF(block) == Proc){
    Proc な yield
  }
  else if(CLASS_OF(block) == Block){
    Block な yield
  }
}


> どうせ多くの場合FullProcにcanonicalizeすることになるんじゃないか、だと
> したらEasyProc なんて用意する意味はないんじゃないか、という意図です。

　私は上記のとおり，根拠もなく easy なのばっかりじゃん？　と
思っていたので，一度しっかり検証する必要はあるかもしれません．

　Ruby で Proc って，ほんとにそんなに使うかなぁ？

  x.times{|i|
    hogehoge
  }

　はよく使いますけど，Proc オブジェクトを生成する必要はない
ですよね．

　というわけで，期間中にベンチマークプログラムを作って調べて
みます．

　あー，ベンチマーク用の何かも集めたりしないといけなかったなぁ．


> また、「EasyProcを作って渡したけれど、呼び出された側は名前のある引数で
> 受けとった」とすると、それをチェックしてFullProcに変換しなければなりま
> せんよね。最初から何も考えずにFullProcを作る場合よりオーバーヘッドがか
> かります。

　EasyProc 生成のコストは 0 なので，「よりオーバーヘッドが増える」
ということはないと思います．

	def m cond
	  a = 1
	  if cond
	    iter{
	      ...
	    }
	  else
	    ...
	  end
	end

	m

　のようなコードがあったとき，m を実行した瞬間 m の環境をヒープ
に移すということですよねぇ．あれ，iter を実行した瞬間に，m の環
境を保存？


> いずれにせよ、EasyProcを作るなんていう最適化は完全にoptionalですから、
> 後回しにして良いんではないかと思います。

　実は，さきにそっちを作っちゃったんです orz．楽だから．


-- 
// SASADA Koichi at atdot dot net
//

--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml