> There have been several projects that attempt to translate high level 
> languages into C (e.g., the Scheme Chicken compiler).  However, I don't 
> know why you would want to do this for Ruby now that 1.9 uses a proper 
> VM.  Instead of developing a compiler to target C, why not just target 
> the YARV bytecode?  

Perhaps you can explain this slightly more so I know what you meant 
exactly?  As you mentioned there's kind of two sides to the 
optimizing--the initial static stuff and the dynamic "oh this has 
changed let's recompile" stuff.  Ahh so you are referring to the dynamic 
side when you refer to "targeting bytecode"?

> If you are trying to really optimize Ruby, then 
> you'll likely want both static optimizations (generating efficient 
> bytecode, minimizing GC pressure), and dynamic optimizations (hotspot 
> JIT compilation).  The latter is especially important for Ruby since you 
> could support for features like eval (just eject any optimizations that 
> are invalidated by the eval'd code and recompile as necessary).  In 
> fact, I believe that many of the ideas that went into making the JVM so 
> efficient came out of the Smalltalk community's work on optimizing 
> dynamic VMs.

Yeah I still wish for a psyco for Ruby -- wishes are cheap.  I'd imagine 
the first step is to get the static side going, though, hence my 
focusing on that.
I suppose that's all you'd need for "small scripts that don't use eval 
or change methods after a fixed load time"
but you're right--being able to JIT compile [either to c, like ruby 
inline, or to llvm/libjit] would be best.  There have been some limited 
efforts in this regard (ludicrous, jruby), but not much for KRI.
Thoughts?
-=r
-- 
Posted via http://www.ruby-forum.com/.