Re: In support of guile-emacs

[Taylan Ulrich Bayırlı/Kammer]

Alan Mackenzie <address@hidden> writes:

> Hello, Taylan.
>
> On Mon, Oct 19, 2015 at 06:56:47PM +0200, Taylan Ulrich Bayırlı/Kammer wrote:
>> Alan Mackenzie <address@hidden> writes:
>
>> > Hello, Daniel.
>
>> > On Mon, Oct 19, 2015 at 07:14:55AM -0700, Daniel Colascione wrote:
>> >> On 10/19/2015 03:24 AM, Alan Mackenzie wrote:
>> >> > Hello, Xue.
>
>> >> > On Mon, Oct 19, 2015 at 09:07:59AM +0800, Xue Fuqiao wrote:
>
>> >> >> guile-emacs replaces Emacs's own Emacs Lisp engine with Guile's 
>> >> >> (without
>> >> >> breaking backward compatibility).  So:
>
>> >> >> * Emacs Lisp will execute faster (Guile VM bytecode is more efficient)
>
>> >> > Just as a matter of interest, approximately how much faster is Guile
>> >> > bytecode than Emacs bytecode?  Are we talking about 10%, 20%, 50%, a
>> >> > factor of 2, or even higher?
>
>> >> > If that speed increase was significant, it might be worth incorporating
>> >> > Guile's bytecode into Emacs just for that reason, regardless of any of
>> >> > the other stuff.
>
>> >> Or simply making completely independent and custom-tailored improvements
>> >> to the Emacs bytecode compiler and interpreter itself. There's no reason
>> >> to imagine that the only way to improve performance there is to move to
>> >> a completely different runtime.
>
>> > Indeed not.  Lessons could be learnt from Guile, perhaps.  But how much
>> > faster is Guile bytecode?
>
>> For the record, the unreleased Guile 2.2 uses a register VM (instead of
>> a stack VM), and has a different intermediate language on which more
>> optimization is done.  There's prospect for native code compilation too
>> for the future, from what I gather.  So Guile's performance isn't
>> exactly fixed at its current state, and improvements are happening at a
>> pretty impressive rate.
>
> A true politician's (non-)answer.  ;-)

Politician?  Don't insult me! :-P

I actually did some silly looping tests, but decided not to post them.
As far as the silly loops were concerned, there wasn't much difference.
Elisp's dotimes counts to ten million slightly faster than Guile's 'do'
with explicit counting (best approximation of 'dotimes' I could come up
with).  Guile iterates over a list of ten million elements faster.  It
didn't seem worthwhile to post; silly loops are just silly loops.
(Incidentally, silly loops got faster in Guile 2.2![0] Apparently
non-silly loops also got faster though.[1])

[0] http://wingolog.org/archives/2013/11/26/a-register-vm-for-guile
[1] http://wingolog.org/archives/2015/07/28/loop-optimizations-in-guile

And here some fun; when I tried to imitate dotimes with a "named let"
loop instead of 'do':

> ,time (let loop ((i 0)) (unless (= 10000000) (loop (+ i 1))))
;; 0.002618s real time, 0.002607s run time.  0.000000s spent in GC.

What?!  That's way too fast.  Oh wait...

> ,optimize (let loop ((i 0)) (unless (= 10000000) (loop (+ i 1))))
$2 = (if #f #f)

Oh, heh.  A void 'do' loop doesn't get the same treatment because of
slightly different semantics, but a void named-let loop simply gets
eliminated out.

> Is the Guile VM, in fact, faster than the Emacs byte interpreter?  Who's
> done any measurements?  Surely the speed advantage/disadvantage of the
> Guile VM will depend, possibly a lot, on what program is being tested,
> but has anybody actually done any actual benchmarking?

I would also like to know, really.  I don't know what good benchmarks
might be that are both realistic and show the benefits of Guile's added
optimization passes and such.  At the same time though, I'm really very
hopeful about Guile's future wrt. performance.  A very great hacker is
working on it.

Taylan