This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: How fast will the Guile VM be?
Chris Cramer <crayc@kiwi.pyro.net> 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
compilation.
Good references include:
http://www.idiom.com/free-compilers/LANG/Scheme-1.html
http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/lang/scheme/part2/faq.html
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/scheme/impl/
http://www.schemers.org/Implementations/
http://www.cs.indiana.edu/scheme-repository/imp.html
http://www.swiss.ai.mit.edu/projects/scheme/index.html
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.
scheme48
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
hjstein@bfr.co.il
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user