Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled

[Ken Raeburn]

On Aug 4, 2009, at 09:52, Marijn Schouten (hkBst) wrote:
> A more idiomatic way to implement it that also works in other  
> Schemes is:

I know, shame on me for using "set!" in my code. :-)
I was aiming for code very similar between Lisp and Scheme versions,  
so that (insert some hand-waving here) it might be more reasonable to  
compare Emacs and Guile performance; named loops wouldn't work for  
Lisp, tail-recursive functions don't get optimized into loops in Emacs  
Lisp, etc.  So while loops with explicit setting of new values seemed  
like a good compromise.  (Then again, like I said, I was aiming for  
something to exercise the GC system in particular, and failed there  
anyways.)  It would've been better still if I'd pulled up the elisp  
branch and compared that against Emacs for processing the same Lisp  
code....

> On my machine larceny computes (A 3 9) in 83 ms and (A 4 1) in less  
> than 22
> seconds. In guile-1.8.6 this version is also twice as fast as your  
> version for
> (A 3 9); they run 9s and 18s respectively. I haven't tried the new  
> guile
> compiler yet.

Thanks!
The compiler geek in me wants to suggest that the compiler should be  
able to transform away most of the differences and the performance  
should be nearly the same. :-)  (The compiler geek in me also knows  
better than to expect it.)

For completeness, the timings I get for A(3,9) with your version, on  
the same machine I used before:

1.8.7:                8.4s
1.9.1, not compiled: 13.1s
1.9.1, compiled:      2.8s

I also tried A(4,1) in the compiled version, and it took 13m20s.  So  
the 1.9.1-compiled version of your code, from two data points, appears  
to be only a bit slower than the byte-compiled Emacs version.

Ken