Re: In support of guile-emacs

[Alan Mackenzie <acm@muc.de>]

Hello, Taylan.

On Mon, Oct 19, 2015 at 06:56:47PM +0200, Taylan Ulrich Bayırlı/Kammer wrote:
> Alan Mackenzie <acm@muc.de> 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.  ;-)

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?

> Taylan

-- 
Alan Mackenzie (Nuremberg, Germany).