[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: compiler for ruby
From:       "M. Edward (Ed) Borasky" <znmeb () cesmail ! net>
Date:       2007-03-31 16:12:36
Message-ID: 460E884E.1020402 () cesmail ! net
[Download RAW message or body]

Rick DeNatale wrote:
> Yes there are a variety of approaches to compiling Ruby to either Java
> bytecodes (e.g. XRuby) or bytecodes more specifically tuned to Ruby
> semantics (e.g. YARV which is now in Ruby 1.9).  I think most people
> these days think that bytecode == Java bytecode, but the idea preceded
> Java.
I first encountered the idea of a "virtual machine" for reasons of 
portability in the early 1960s. However, the idea probably predates that 
and goes back to the very early days of computer languages.
>
> As of today YARV seems to be the best performing, at least according
> to the benchmarks I've seen.
>
> As for compiling directly to machine code, it could be done I suppose,
> but it's not clear that it would be the best approach. Why?
>
>   * The dynamic nature of Ruby means that methods can be dynamically
> created at run-time and would therefore need to be compiled at
> run-time.  Additional bookkeeping would be required to make all the
> semantic effects on the compiled code would be properly implemented.
>
>  * Previous experience with compiling dynamic OO languages has shown
> that the much smaller code representation of byte codes compared to
> machine code can actually lead to better performance on machines with
> virtual memory (almost all machines these days) due to the smaller
> working set.  Digitalk tried direct compilation of Smalltalk to
> machine code, because they were sick of getting blasted for being
> 'interpreted' and found that the byte coded stuff ran significantly
> faster. The practice these days is to do two-stage compilation, first
> to byte-codes, and then to machine code for selected code when the
> run-time detects that that code is frequently executed.
The prototype for a lot of this is (most implementations of) Forth. 
There is an "inner interpreter", which was originally indirect threaded 
for portability. However, it can be direct threaded, which is faster, 
subroutine threaded, which is still faster, or "token" threaded, which 
is the most compact. This last corresponds most closely to what we think 
of as "byte code".

Yes, compactness of code is indeed a virtue on "modern machines", 
although I suspect it's more an issue of caching than virtual memory. By 
the way, in "reality", I don't think Ruby is any more "dynamic" than 
languages we normally think of as "static". Almost any decent-sized 
program or collection of programs is going to have things that are bound 
early and things that aren't bound till run time, regardless of what 
languages the implementors used.


-- 
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.


[prev in list] [next in list] [prev in thread] [next in thread]