[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How fast will the Guile VM be?

From: Harvey J. Stein
Subject: Re: How fast will the Guile VM be?
Date: 05 Sep 2000 13:10:20 -0400

Chris Cramer <address@hidden> writes:

 > I am not aware of any Scheme compiler that compiles to native code.
 > The fastest Scheme compiler is Stalin (or at least, that what everyone
 > says), and it only compiles to C.
 > Bigloo and Hobbit compile to C as well... MIT Scheme and MzScheme compile
 > to bytecode or something I think. Kawa compiles to Java bytecode, and
 > it may be possible to recompile that to native code via gcj.
 > > There are lots of Scheme compilers/interpreters, so I don't quite
 > > understand which one has what feature.  Is there a good summary of
 > > features/benchmarks between several systems?

As other's have pointed out, MIT Scheme, Chez Scheme, and Twobit (the
Larceny compiler) generate native code directly.  The old Gambit does
too.  PCS/geneva seems to compile to native code.

Bigloo, Stalin, Gambit, scheme-to-C & Hobbit generate C code.

Oaklisp & VSCM have bytecode compilers.

RScheme & MzScheme compile to both bytecode & C code.

Open scheme has a compiler that generates C code & they're planning on
developing a byte code compiler.

STk, Elk, scsh, scheme48 (AFAIK) don't have compilers, but I believe
they do various things on the fly which are similar to bytecode

Good references include:

I went through these & the referenced homepages/ftp sites to cross
check the above list.

 > I could tell you what my impressions are. Generally, there are two
 > performance measures, startup time and run time... (this is far
 > from scientific)
 > Guile: large startup time, moderate run time
 > Bigloo: moderate startup time, moderate run time
 > MzScheme: small startup time, moderate run time
 > Stk: small startup time, large run time
 > Stalin: small startup time, small run time
 > SCM: small startup time, small run time
 > Hobbit (w/Guile): large startup time, small run time

I've done some scheme implementation benchmarking.  I'd order
implementations I've tried out as follows (from memory):

   Stalin, gambit, Bigloo
       Stalin is usually fastest, but gambit & bigloo are sometimes
       equally fast or faster if you tell them to dump generic
       arithmetic.  Stalin tends to figure it out on its own.
   Scheme->C, Hobbit
       Tend to produce substantially slower code than the other
       compilers, although Hobbit can sometimes produce fast code.
       Last I checked (a couple of years ago), Hobbit sometimes does
       things that would seem to be faster but turn out slow.  One
       example which comes to mind (if I recall correctly) was
       replacing (- x 1) with (1- x).
   STk, scm, Bigloo interpreter, Gambit interpreter, guile.
       Tend to be about the same.  Each one wins some & loses some.
       Guile tends to lose the most, but I think it's a little better
       now.  scm often toted as being a fast compiler & people say
       that STk is slow, but I've found them to be about the same.
       It has slow numerics which tend to cause it to benchmark
       worse than it probably is in practice.

I don't remember how RScheme does - I think I had trouble getting a
properly functioning interpreter/compiler at the time I was
benchmarking things.  And I haven't tested the others much.

 > As far as run time, I have examined the output of Stalin, Hobbit,
 > and Bigloo; even Stalin is far from optimal... I think they're
 > mostly limited by the target language though.

Stalin's output tends to look worse than it really is.  It
specifically depends on the C compiler's optimizer (as in "I don't
have to deal with this - the C compiler will").

 > I wonder if someone should do a Scheme add-on for gcc.

Could be done, but you'd still probably need a separate runtime
interpreter.  Also, getting gcc to be fully tail recursive probably
requires using different calling conventions from normal C code (the
callee has to be responsible for popping the stack instead of the
caller).  Even aside from this there are other issues with gcc
recognising tail recursion.  It's also not clear how much more
optimization you could get from being inside gcc vs just giving gcc
C code.

Harvey Stein
Bloomberg LP

reply via email to

[Prev in Thread] Current Thread [Next in Thread]