ささだです。

        Sat, 24 Jul 2004 12:05:02 +0900 の
        [yarv-dev:116] Re: another project


matz> |・YARVの利点、.NET Compilerの欠点：
matz> |
matz> |1. IL（中間言語）の仕様がyarvのはRuby的に有利
matz> 
matz> これは大きいと思います。動的な言語からILにトランスレートしよ
matz> うとしている人たちはみんなここに引っかかっているようです。型
matz> 情報のない状態でメソッド呼び出しを行おうとするとemitを使うし
matz> かないのですが、これがめちゃめちゃ遅いそうです。伝聞ですが。

　不勉強なのですが、 emit ってどういうものなのでしょうか。

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemreflectionemit.asp

NET Framework Class Library   

System.Reflection.Emit Namespace
The System.Reflection.Emit namespace contains classes that allow
a compiler or tool to emit metadata and Microsoft intermediate
language (MSIL) and optionally generate a PE file on disk.
The primary clients of these classes are script engines and compilers.

　これのことでしょうか？

この中の

NET Framework Class Library   

MethodBuilder.Invoke Method

Overload List
Dynamically invokes the method reflected by this instance on the 
given object, passing along the specified parameters, and under 
the constraints of the given binder.

　を使うのかなぁ。（名前だけ見て適当に選びました）


matz> 一種のラッパーで対応できるんじゃないかと思います。.NETでも可
matz> 能なのかなあ。

　一番気になるのは setjmp/longjmp による例外処理との相性です。


matz> |・不明
matz> |
matz> |- C の今までのライブラリとの互換性がとれるのかな？
matz> |- GC とかどうなるんだろう
matz> |- 例外機構はすんなり乗るんだろうか
matz> |- eval とか動くのかなぁ（環境管理的に）
matz> |- 何が彼をこれに向けさせたんだろう
matz> 
matz> 「Cのライブラリはステ」、「GCは.NETのもの」、「例外はたぶん
matz> 大丈夫」、「evalはステ(あるいはcompile+go)」と推測します。

　私もだいたいそんな感じだと思いました。eval は、環境管理ができれば
いけると思うんだけど（ダイナミックなバイトコード生成はできるだろう）


matz> |・まとめ
matz> |
matz> |　1 と 3 のトレードオフですよねぇ。多分。首藤さんには 3
matz> |によって .NET の勝ち〜って一刀両断されちゃったんだけど、
matz> |Groovy の処理速度とか見ると、やっぱりそんな簡単じゃない
matz> |んじゃないかと思います。（と思わせて orz）
matz> 
matz> emit回避ができるかどうかで決まるでしょう。私はyarvが(速度的
matz> に)勝つ方に賭けるな。

（よく考えたら、私の書いた「トレードオフ」という言葉は的外れ
でしたね）

　MSさんも、そこがボトルネックになるということがわかれば、必ず
何か手を打つと思うのですが。そんなことないかな（その他の（サード
パーティの）言語を速くする、という目的のプライオリティは高くない？）

　まぁ、ちょっと考えれば、メソッド呼び出し毎にライブラリコールが
入ったらいかに JIT compiler が頑張っても速くなりそうはないですねぇ。



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