Re: Elisp performance

[Daniel Kraft]

Hi Ken,

Ken Raeburn wrote:
> On Jul 31, 2009, at 02:02, Daniel Kraft wrote:
> > > > Iterative prime sieve, (length (find-primes-to 5000)):
> > > >  Scheme: 0.42s
> > > >  Elisp, no void checks, lexical let: 3.40s
> > > >  Elisp, no void checks, dynamic let: 4.43s
> > > >  Elisp, void checks, dynamic let: 5.12s
> > > >  Elisp, void checks, lexical let: 4.06s
> > > As Ken says, it would be good to see an Emacs timing too.
> >
> > I'd like to provide one, but have no idea how to do so...  I just 
> > managed to find out how to evaluate elisp code from a buffer, but it 
> > would be cool to get some elisp REPL if possible (maybe even without 
> > starting emacs itself and just from a shell?) -- and how to I time?  
> > As well as byte-compile and time then?
[...]

Thanks for the emacs hints!  For the prime sieve, emacs itself takes 
about 1.89s (interpreted) and 0.32s (compiled).  So it's significantly 
faster than my elisp version at the moment, the reason might be the 
performance hit from the primitive calls already discussed (but I don't 
know).  And the compiled version is even faster than Guile runs the 
Scheme code.

The "tight loop" takes in emacs about 0.91s (interpreted) and 0.26s 
(compiled) when using lexical-let and 0.58s / 0.16s when using dynamic 
binding.  So with the manual guile-primitive hack, my version actually 
reaches emacs here; which is still quite unfair of course, as my code is 
faster with lexical-let and emacs is slower...

> > Ok, I guess a quick summary is in order:  I think implementing dynamic 
> > binding directly using dynamic-wind instead of with fluids is a good 
> > idea, as long as we don't already want to keep the fluids for future 
> > multi-threading.  If this ever comes, we are probably again forced 
> > back to fluids.  Do you think we should switch or not?  Regarding tail 
> > calls, my opinion is that there's no "easy" way to make them work with 
> > dynamically bound arguments (as arguments are in elisp), if there is 
> > at all -- and that we should not bother.  I don't think emacs does 
> > general tail-call optimization (does it?), and there will be a way to 
> > switch lambda arguments back to lexical scoping, so that for those 
> > lambda's tail-calls will be optimized just fine with the current 
> > compiler/VM infrastructure.
>
> If the new thread keeps running while the creating thread exits the 
> scope that created a dynamic binding, while the new thread wants to keep 
> using or updating it... ugh.

Yep, so I think we should either make dynamic bindings thread local 
(keep the fluids) or make them global with the problems of concurrent 
access but simply declare they are unsafe to use with multiple threads 
and users should instead use lexical bindings in relevant code.

I did not get your opinion about which of these ways to go for dynamic 
bindings...  From my point of view, both have quite advantages and 
disadvantages; fluids are cleaner and can be used in the multi-threaded 
context (should it become topical), but getting rid of them with 
dynamic-wind promises better performance and simpler working when single 
threaded.  Maybe we could even provide both implementations to choose 
for the user, I'll investigate how much effort that would be and what 
problems there arise.

Yours,
Daniel

--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri