Re: In support of guile-emacs

[Alan Mackenzie]

Hello, Taylan.

On Mon, Oct 19, 2015 at 08:50:16PM +0200, Taylan Ulrich Bayırlı/Kammer wrote:
> 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

OK.  Never again!

> 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; ....

_Any_ real timings are better than hand waving.  Sophisticated testing
can wait until things are ready for them.

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

That's a loop of 10,000,000 taking 2.618e-3 seconds.  That would be
2.6e-10 seconds per iteration, or approximately 4.0e9 iterations per
second.  With a 4 GHz processor, that's 1 clock cycle per iteration.  It
seems likely that some processing has been optimised away.

When I run this in Emacs on my 2.6 GHz Athlong machine, with M-:

  (time-it (let ((i 0)) (while (<= i 10000000) (setq i (1+ i)))))

, this takes 1.8881s.  (`time-it' is my own macro, not a standard Emacs
one.)  So, thus far, it's looking like Guile is a factor of ~700 faster.
:-)

> > ,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.

Ah.  Shame.  How about calculating 1 + 2 + 3 + .... + 10,000,000 in a
loop, then outputting it?  The sum (50,000,005,000,000) should easily fit
into a 64-bit Lisp integer.

This:

  (time-it (let ((i 0) (s 0)) (while (<= i 10000000) (setq s (+ s i)) (setq i 
(1+ i))) (message "%s" s)))

takes 3.389s on my machine.

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

If Guile Emacs is advanced enough, timing the fontification of a file
(say, ..../src/xdisp.c in our repository) would be a very meaningful
timing.

> At the same time though, I'm really very hopeful about Guile's future
> wrt. performance.  A very great hacker is working on it.

That's encouraging.

Thanks.

> Taylan

-- 
Alan Mackenzie (Nuremberg, Germany).