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] |
karlheg@inetarena.com (Karl M. Hegbloom) writes: > I recently tried the usual factorial function: <snip> > ... in several Scheme and Common Lisp implementations, and ran it as > (fact 500). Most of the interpretters, including `guile', take a few > seconds of processing before they print out the huge number. Some > are faster than others. I didn't actually time them, my results are > subjective. > > One scheme though, Gambit-C 3.0's `gsi', prints the result almost > instantly. Wow! It's really fast! The speed difference is very > noticable, and quite surprising. > > I wonder if there's anything to be learned from the Gambit-C 3.0 > implementation that could be used to improve the speed of guile? > What does he do that makes it so quick? You're testing the speed of bignum multiplication & of bignum printing. The pause is probably in the interpreters computing the decimal digits of the result. First off, test with doing the computation but not doing the printing. In scheme do: (define f (fact 500)) to get the computation without the output. Then check the speed of printing bignums by outputing the value of f. I expect that you'll find the difference in speed mostly to do with the printing, with gambit having a better bignum printer. BTW, with STk, (fact 500) is also very fast. It uses the Gnu multi-precision package for bignums which is quite efficient. I have to do (fact 3000) before noticing a pause, but this is on a Pentium II 300. On a 486-66, the pause for (fact 500) is barely noticable & might just be due to the fact that I was connecting to it over a frame relay line (with 50-100ms ping times). Checking the source code, gambit implements bignums in scheme (see lib/_num2.scm), so that fact that it's so fast is a tribute to the implementation both of bignums & of the compiler itself. It also helps that he's exposed all of the underlying untyped functions so he can type check the arguments at the top & dispense with type checking afterwards. BTW, it seems to be a sparse representation, so it might be trading space for speed. Also, if you're interested in investigating further, it looks like it uses number->string to output numbers. For bignums it calls ##bignum.number->string*, which is implemented in lib_num2.scm. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il