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] |
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