This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: librep's indirect threaded bytecode interpretter
- To: Michael Livshin <mlivshin at bigfoot dot com>
- Subject: Re: librep's indirect threaded bytecode interpretter
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 22 May 2000 10:20:26 +0200
- Cc: karlheg at bittersweet dot inetarena dot com (Karl M. Hegbloom), guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <87g0rb6u4s.fsf@bittersweet.intra> <s3snvbxb1g.fsf@bigfoot.com>
Michael Livshin <mlivshin@bigfoot.com> writes:
> karlheg@bittersweet.inetarena.com (Karl M. Hegbloom) writes:
>
> > I ran a simple benchmark today, between `rep'
> > and `guile'. I defined an iterative factorial function, (the classic
> > one that passes an accumulator and (1- n) via a tail-call), and ran
> > it 1000 times in a loop with (fact-it 1 400). Guile took almost a
> > minute to finish, and `rep' finished in about 5.2 seconds.
>
> hmmm... actually, this looks more connected to the fact that Rep uses
> the GMP library and Guile doesn't.
I think you're right. When using the "prime" benchmark included
below, rep is 30% faster than Guile on my machine.
But it *is* time to start thinking about changing the evaluator to get
more speed. As well as looking in the rep direction, we might also
look at QScheme.
Personally, I now suspects that a byte-code interpreter can be faster
than a tree interpreter ever can be.
(compile "prime.jl" using (compile-file "prime.jl"))