This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: performance


Andres Heinloo <lka@physic.ut.ee> writes:

> I wrote two nested tail-recursive loops and I counted the iterations
> of outer loop during 1 minute since executing (load
> "loop-test.scm"). The test program (a rather stupid one) is
> attached. Results were the following:
> 
> SCM 5d0         625
> MzScheme 53     535 (.scm)
>                1063 (.so)
> SIOD 3.5        109
> Guile 1.3        70

Your measurements seem to indicate that Guile is 900% slower than SCM
5d0 for your program.  I tested your program in the normal Guile
evaluator (Guile by default uses a debugging evaluator which can be
switched off with (debug-disable 'debug)) and compared to SCM 5d0 on
my 66 MHz laptop.  I got the numbers 181 and 127, i.e., Guile being
43% slower than SCM for your program.

I'm a bit surprised to see a 43% difference between SCM and Guile.
We have been careful not to add things that should slow down the
evaluator noticeably.  Since the Guile descends from SCM, the reason
for the difference probably isn't that Guile has become slower but
that SCM has become faster.

It seems that SCM has got something called environment caches.  My
guess is that they make it possible for SCM to avoid consing when
building argument lists.  (If you look at the time spent in GC it is
almost 0 for SCM but substantial in Guile.)

But that component of execution speed should get less significant when
evaluating real programs.  I made a quick test using Aubrey Jaffer's
pi.scm:

  (do ((i 0 (+ i 1))) ((= i 10)) (pi 100 5))

This loop took 9.5 s in SCM 5d0 and 10.7 s in Guile, i.e. Guile being
13% slower than SCM.

Now we're down to figures which make the execution speed less
important when making the choice between interpreters...

(It should be noted that Guile's execution speed can be seen shifting
 randomly back an forth within an interval of 30% during development
 due to added code or code moving around in the compilation modules.
 This probably has to do with the behaviour of the CPU cache.  So 13%
 is within the margin of random error...)

Of course it would still be good to pick up on the recent development
of SCM.

/mdj