In support of guile-emacs

In support of guile-emacs

[Christopher Allan Webber]

There's been a lot of conversation on this list that's been discussing
whether or not the Guile port of emacs could be a good basis.  I've
advocated it in the past, and I'm advocating it further here.  I think
it's a solid direction, but what it really needs is *work* at this
point.  If you'd read the list lately though, you'd think the move was
on the order of getting a settlement on Mars.  But much of the work has
already been done.

guile-emacs (for lack of a better term at the moment) works, and it
works already.  Here's a screenshot I took 5 months ago:

  http://dustycloud.org/tmp/guile-emacs-20150513.png

And a less nice screenshot, but even back in February:

  http://dustycloud.org/tmp/guilemacs.png

I can run orgmode, I can hack lisp, I can play tetris!  Most of my
.emacs loads along with all the extensions implied.  Most of the things
I do day to day in emacs already work.  There is much work to be done,
and I'll come back to this, but I want to re-emphasize: guile-emacs is a
*real thing* you can try *today*.  In fact, if you have the Guix package
manager, you can try it right now, because I packaged it for Guix:

  guix package -i guile-emacs

Take a minute and think about it... that means that *a hell of a lot of
the things that already need to be done are already done*!

So guile-emacs runs, and unlike many other discussions that have been
discussed on list... is a real thing!  A thing you can use today!

But there is work to do.  The main thing that is needed is someone needs
to step up and *do this work*!

 - More work likely needs to be done on the strings side, but solutions
   have been discussed on list, and even in the case of transforming
   from bytevectors -> guile strings and back again, it's no big deal.
   I mean, there's work *to do*, but it isn't an impossibility.  We have
   the means of abstraction, and this can be achieved.
   Nonetheless, it seems like we're cycling nonstop on this issue,
   but it really just needs to be *worked on*.

 - It's slow.  But it's slow for mostly known reasons!  When I last
   talked to BT Templeton about this, they told me that they had a list
   of optimizations to do, especially around supporting dynamic scoping
   aspects.

 - There are bugs I ran into, but far fewer than expected.  More
   astounding is just how much works at this stage, IMO.

The "emacs rewrite" thread originally started out with "is C not a
maintainable language, and should it be rewritten in scheme?"  I
personally think emacs' C core is fine, but maybe over time things can
be refactored more into emacs lisp, or if guile-emacs were chosen,
scheme.  (I hear that Ludovic thinks libguile may replace much of it
anyway, but this is hardly my area.)  There's some other conversation on
the list that seemed to suggest something more hip to attract current
developers, but I think "The Emacs Problem" still applies: there's
nothing more flexible than s-expressions out there, and emacs maximizes
that:

  https://sites.google.com/site/steveyegge2/the-emacs-problem

I personally think Guile Emacs is an amazing project with a potentially
brilliant future ahead.  It is missing something though, and that's
regularly active hackers.  BT Templeton's work has broken a lot of
ground, though the project could use more active people.

The current guile-emacs FUD on list, I think it's pretty repetitive
and uninteresting.

But if you're really interested in a Glorious Emacs Future (TM),
guile-emacs might actually be that future you want!  You can try it
right now, it already runs!  (Just expect rough edges!)  And if you want
to make that future happen, it would be great to see you dig in.

Re: In support of guile-emacs

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On 18 Oct 2015 9:48 pm, "Christopher Allan Webber" <cwebber@dustycloud.org>
wrote:
> But if you're really interested in a Glorious Emacs Future (TM),
> guile-emacs might actually be that future you want!  You can try it
> right now, it already runs!  (Just expect rough edges!)  And if you want
> to make that future happen, it would be great to see you dig in.

There's one thing I still don't know. Which of the following items is the
purpose of guile-emacs? (select more than one if appropriate)

1. Write the underlying core in scheme instead of C.
2. Offer scheme as an alternative to elisp because it's faster.
3. Offer scheme as an alternative to elisp for some other reason (if so,
which?).

[-- Attachment #2: Type: text/html, Size: 882 bytes --]

Re: In support of guile-emacs

[Xue Fuqiao]

Hi Artur,

On Mon, Oct 19, 2015 at 7:12 AM, Artur Malabarba
<bruce.connor.am@gmail.com> wrote:

> There's one thing I still don't know. Which of the following items is the
> purpose of guile-emacs? (select more than one if appropriate)
>
> 1. Write the underlying core in scheme instead of C.
> 2. Offer scheme as an alternative to elisp because it's faster.
> 3. Offer scheme as an alternative to elisp for some other reason (if so,
> which?).

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)
* It will be easier for Emacs Lisp to implement some new language features
* Emacs Lisp will be able to interoperate with languages on the Guile VM
  (not only Scheme)

So I think all 3 points are purposes (or side-effects) of guile-emacs,
although the first one should be "write *a part of* the underlying core
in Scheme".

I think one of the "some other reason" should be "satisfying people who
like Scheme (or other languages run on the Guile VM) because it's
cleaner and simpler than Emacs Lisp".

Re: In support of guile-emacs

[Alan Mackenzie]

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.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: In support of guile-emacs

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

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

A good part of the speedup is with GUILE's compiler stack that
facilitates structural optimizations better than the Emacs
byte-compiler.  Of course, the compiler stack depends on a lot of Scheme
facilities again.  So it's not all that easy to cherry-pick.

-- 
David Kastrup

Re: In support of guile-emacs

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: In support of guile-emacs

[Alan Mackenzie]

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?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: In support of guile-emacs

[Taylan Ulrich Bayırlı/Kammer]

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.

Taylan

Re: In support of guile-emacs

[Alan Mackenzie]

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

Re: In support of guile-emacs

[Taylan Ulrich Bayırlı/Kammer]

Alan Mackenzie <acm@muc.de> writes:

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

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

Re: In support of guile-emacs

[Dmitry Gutov]

On 10/19/2015 09:50 PM, Taylan Ulrich Bayırlı/Kammer wrote:

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

I could suggest a couple real benchmarks (time to parse jquery.js with 
js2-mode, or decode, or encode a large JSON document with json.el), but 
all these operate with strings a lot. IIUC, that's still a WIP area, so 
the results might not highlight Guile's benefits appropriately.

Re: In support of guile-emacs

[Taylan Ulrich Bayırlı/Kammer]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 10/19/2015 09:50 PM, Taylan Ulrich Bayırlı/Kammer wrote:
>
>> 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.
>
> I could suggest a couple real benchmarks (time to parse jquery.js with
> js2-mode, or decode, or encode a large JSON document with json.el),
> but all these operate with strings a lot. IIUC, that's still a WIP
> area, so the results might not highlight Guile's benefits
> appropriately.

Well, GuileEmacs isn't ready for benchmarks at all yet.  I rather had
Emacs-Elisp vs. Guile-Scheme benchmarks in mind, but sure, Emacs-Elisp
vs. Guile-Elisp is the real question.

Maybe it's best to wait a bit longer so we can do really real benchmarks
on js2-mode, ansi-term, IDO, and what have you.  (IDO on directories
with very many files is one of the few real-life cases of Elisp slowness
I hit.)

Taylan

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 <acm@muc.de> writes:

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

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

Re: In support of guile-emacs

[Taylan Ulrich Bayırlı/Kammer]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Taylan.
>
> [... snip ...]
>
>> 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.

You're right, that may have been overly hand-wavy...

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

Oh oh, don't forget to byte-compile Elisp.  Was my first mistake too.

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

Takes about 0.62s here, when byte-compiled.  The Guile variant:

(let ((i 0) (s 0))
  (while (<= i 10000000)
    (set! s (+ s i))
    (set! i (1+ i)))
  (format #t "~s" s))

Takes about 0.55s.  That's a very literal transcription of the function
to Scheme.  A more idiomatic version:

(let loop ((i 0) (s 0))
  (if (<= i 10000000)
      (loop (+ i 1) (+ s i))
      (format #t "~s" s)))

Takes about 0.50s.

BTW here's a timing function that automatically byte-compiles the
argument (side-effectfully if a symbol):

(defun time (function)
  "Return execution time of calling FUNCTION in seconds as a
float.  FUNCTION is byte-compiled automatically."
  (setq function (byte-compile function))
  (let ((start (current-time)))
    (funcall function)
    (let ((end (current-time)))
      (let ((time (time-subtract end start)))
        (+ (* (nth 0 time) (expt 2 16))
           (nth 1 time)
           (/ (nth 2 time) 1000000.0))))))

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

I'm guessing that Guile Emacs isn't ready for that yet but, how can one
time that?

Taylan

Re: In support of guile-emacs

[Alan Mackenzie]

Hello, Taylan.

On Mon, Oct 19, 2015 at 11:01:21PM +0200, Taylan Ulrich Bayırlı/Kammer wrote:
> Alan Mackenzie <acm@muc.de> writes:

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

> Oh oh, don't forget to byte-compile Elisp.  Was my first mistake too.

Hah!  Yes, I had forgotten to byte-compile it.  Creating a defun for it,
then timing that I get 0.495s.

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

Again, byte-compiled, that takes 0.957s.

> Takes about 0.62s here, when byte-compiled.

Your machine is ~50% faster than mine.

The Guile variant:

> (let ((i 0) (s 0))
>   (while (<= i 10000000)
>     (set! s (+ s i))
>     (set! i (1+ i)))
>   (format #t "~s" s))

> Takes about 0.55s.  That's a very literal transcription of the function
> to Scheme.  A more idiomatic version:

> (let loop ((i 0) (s 0))
>   (if (<= i 10000000)
>       (loop (+ i 1) (+ s i))
>       (format #t "~s" s)))

> Takes about 0.50s.

So, we're talking about a speed up of around 13%/25% on a simple loop
test, depending on whether or not an idiomatic Scheme formulation is
used.  Given that Guile compiled elisp wouldn't be optimised in this way,
it would guess that the 13% is nearer the mark.  But it would take a few
real life tests to measure this better.

> BTW here's a timing function that automatically byte-compiles the
> argument (side-effectfully if a symbol):

> (defun time (function)
>   "Return execution time of calling FUNCTION in seconds as a
> float.  FUNCTION is byte-compiled automatically."
>   (setq function (byte-compile function))
>   (let ((start (current-time)))
>     (funcall function)
>     (let ((end (current-time)))
>       (let ((time (time-subtract end start)))
>         (+ (* (nth 0 time) (expt 2 16))
>            (nth 1 time)
>            (/ (nth 2 time) 1000000.0))))))

Hint: there's a function `float-time' which does the job adequately, and
is easier to manipulate.  For comparison, here's my `time-it' macro
(which doesn't itself do byte compilation):

(defmacro time-it (&rest forms)
  "Time the running of a sequence of forms using `float-time'.
Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
  `(let ((start (float-time)))
    ,@forms
    (- (float-time) start)))

[ .... ]

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

> I'm guessing that Guile Emacs isn't ready for that yet but, how can one
> time that?

Start by unfontifying the entire file, then scroll through it, fontifying
a screen at a time.  (sit-for 0) is used to ensure fontification at each
stage.  So something like this (untested) would do the job:

(defun fully-fontify ()
  (beginning-of-buffer)
  (font-lock-mode 0)
  (font-lock-mode 1)
  (condition-case nil
    (while t
      (sit-for 0)
      (scroll-up))))

The `condition-case' catches the error thrown when `scroll-up' reaches
the end of the buffer.

> Taylan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: In support of guile-emacs

[Taylan Ulrich Bayırlı/Kammer]

Alan Mackenzie <acm@muc.de> writes:

> [...]
>
>> (let loop ((i 0) (s 0))
>>   (if (<= i 10000000)
>>       (loop (+ i 1) (+ s i))
>>       (format #t "~s" s)))
>
>> Takes about 0.50s.
>
> So, we're talking about a speed up of around 13%/25% on a simple loop
> test, depending on whether or not an idiomatic Scheme formulation is
> used.  Given that Guile compiled elisp wouldn't be optimised in this way,
> it would guess that the 13% is nearer the mark.  But it would take a few
> real life tests to measure this better.

Indeed, I don't think any conclusions should be drawn from this.

>> BTW here's a timing function that automatically byte-compiles the
>> argument (side-effectfully if a symbol):
>
>> (defun time (function)
>>   "Return execution time of calling FUNCTION in seconds as a
>> float.  FUNCTION is byte-compiled automatically."
>>   (setq function (byte-compile function))
>>   (let ((start (current-time)))
>>     (funcall function)
>>     (let ((end (current-time)))
>>       (let ((time (time-subtract end start)))
>>         (+ (* (nth 0 time) (expt 2 16))
>>            (nth 1 time)
>>            (/ (nth 2 time) 1000000.0))))))
>
> Hint: there's a function `float-time' which does the job adequately, and
> is easier to manipulate.  For comparison, here's my `time-it' macro
> (which doesn't itself do byte compilation):
>
> (defmacro time-it (&rest forms)
>   "Time the running of a sequence of forms using `float-time'.
> Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
>   `(let ((start (float-time)))
>     ,@forms
>     (- (float-time) start)))
>
> [ .... ]

Oh neat.  I forgot we had float-time.

>> > 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.
>
>> I'm guessing that Guile Emacs isn't ready for that yet but, how can one
>> time that?
>
> Start by unfontifying the entire file, then scroll through it, fontifying
> a screen at a time.  (sit-for 0) is used to ensure fontification at each
> stage.  So something like this (untested) would do the job:
>
> (defun fully-fontify ()
>   (beginning-of-buffer)
>   (font-lock-mode 0)
>   (font-lock-mode 1)
>   (condition-case nil
>     (while t
>       (sit-for 0)
>       (scroll-up))))
>
> The `condition-case' catches the error thrown when `scroll-up' reaches
> the end of the buffer.

I had to add the handler `(error nil)' to that, then it worked.

GuileEmacs would first refuse to open xdisp.c, which I thought was a new
feature, but ultimately it opened it. :-)

This is comparing release Emacs to (pre?) alpha GuileEmacs so it
shouldn't come as a surprise (and I didn't care to normalize for X
toolkit) but here goes:

 36.5 seconds with stock Emacs 24.5.1 with no X toolkit from Guix
169.6 seconds with Guile Emacs master branch with GTK from Guix

I think the main problem is a bug that leaks tons of memory and thus
leads to long GC pauses, because GuileEmacs would pause for long times
and reached 700 MB residential memory after it was done.


Since I seem incapable of cooperating with several people on emacs-devel
on typical development topics (see recent drama ... or don't), I guess I
could just devote all my Emacs-related efforts to Guile Emacs.  I still
have a bunch of non-Emacs projects running in parallel though, and I
don't know if I have the Guile *or* Emacs related skills to hack on
this, so don't keep your hopes high.

Taylan

Re: In support of guile-emacs

[John Wiegley]

>>>>> Taylan Ulrich "Bayırlı/Kammer" <taylanbayirli@gmail.com> writes:

> Since I seem incapable of cooperating with several people on emacs-devel on
> typical development topics (see recent drama ... or don't), I guess I could
> just devote all my Emacs-related efforts to Guile Emacs. I still have a
> bunch of non-Emacs projects running in parallel though, and I don't know if
> I have the Guile *or* Emacs related skills to hack on this, so don't keep
> your hopes high.

Seeing your energies devoted to Guile Emacs would be a wonderful outcome,
Taylan, since you'd be mostly apart from the individuals you've had difficulty
working with, but could provide some *much* needed work. There are many of us
who are eager to see if Guile Emacs can succeed in its promise.

John

Re: In support of guile-emacs

[Taylan Ulrich Bayırlı/Kammer]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>> [...]
>>
>>> (let loop ((i 0) (s 0))
>>>   (if (<= i 10000000)
>>>       (loop (+ i 1) (+ s i))
>>>       (format #t "~s" s)))
>>
>>> Takes about 0.50s.
>>
>> So, we're talking about a speed up of around 13%/25% on a simple loop
>> test, depending on whether or not an idiomatic Scheme formulation is
>> used.  Given that Guile compiled elisp wouldn't be optimised in this way,
>> it would guess that the 13% is nearer the mark.  But it would take a few
>> real life tests to measure this better.
>
> Indeed, I don't think any conclusions should be drawn from this.

While we still shouldn't draw any conclusions, I've repeated the test
with master branch Guile now, since it's apparently packaged for Guile
(as "guile-next") and thus trivial to install...

The idiomatic Scheme version:

(let loop ((i 0) (s 0))
  (if (<= i 10000000)
      (loop (+ i 1) (+ s i))
      (format #t "~s" s)))

~0.27s

The Elisp-transcribed-to-Guile version:

(let ((i 0) (s 0))
  (while (<= i 10000000)
    (set! s (+ s i))
    (set! i (1+ i)))
  (format #t "~s" s))

~0.36s

So the idiomatic version provides a ~2.3x speedup, and the literal
transcription ~1.7x.  I'm not sure what exact percent notation you used,
but if it's (x - y) / y * 100 for original time x and new time y, then
these are 130% and 70% which sounds pretty great!


I'd also like to point out that this means the switch from Guile 2.0 to
2.2 (master) entails a 50% speedup of the Elisp-transcribed version (and
a 85% speedup of the idiomatic Scheme version).  This is *still* a silly
loop test, but nevertheless, those are impressive numbers, which I think
gives me a bit of defensibility in what I had said optimistically with
regard to Guile performance having a bright future. :-)

Taylan

Re: In support of guile-emacs

[Alan Mackenzie]

Hello, Taylan.

On Wed, Oct 21, 2015 at 02:54:15PM +0200, Taylan Ulrich Bayırlı/Kammer wrote:
> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> > Alan Mackenzie <acm@muc.de> writes:

> >> [...]

> >>> (let loop ((i 0) (s 0))
> >>>   (if (<= i 10000000)
> >>>       (loop (+ i 1) (+ s i))
> >>>       (format #t "~s" s)))

> >>> Takes about 0.50s.

> >> So, we're talking about a speed up of around 13%/25% on a simple loop
> >> test, depending on whether or not an idiomatic Scheme formulation is
> >> used.  Given that Guile compiled elisp wouldn't be optimised in this way,
> >> it would guess that the 13% is nearer the mark.  But it would take a few
> >> real life tests to measure this better.

> > Indeed, I don't think any conclusions should be drawn from this.

> While we still shouldn't draw any conclusions, I've repeated the test
> with master branch Guile now, since it's apparently packaged for Guile
> (as "guile-next") and thus trivial to install...

> The idiomatic Scheme version:

> (let loop ((i 0) (s 0))
>   (if (<= i 10000000)
>       (loop (+ i 1) (+ s i))
>       (format #t "~s" s)))

> ~0.27s

> The Elisp-transcribed-to-Guile version:

> (let ((i 0) (s 0))
>   (while (<= i 10000000)
>     (set! s (+ s i))
>     (set! i (1+ i)))
>   (format #t "~s" s))

> ~0.36s

> So the idiomatic version provides a ~2.3x speedup, and the literal
> transcription ~1.7x.  I'm not sure what exact percent notation you used,
> but if it's (x - y) / y * 100 for original time x and new time y, then
> these are 130% and 70% which sounds pretty great!

I think I used ((slow time) / (fast time) - 1) * 100, which is probably
an equivalent formula.  But, what the heck?

I'm impressed.  A factor of 2.3, or 1.7 speedup in elisp would be very
worthwhile, IMAO.

> I'd also like to point out that this means the switch from Guile 2.0 to
> 2.2 (master) entails a 50% speedup of the Elisp-transcribed version (and
> a 85% speedup of the idiomatic Scheme version).  This is *still* a silly
> loop test, but nevertheless, those are impressive numbers, which I think
> gives me a bit of defensibility in what I had said optimistically with
> regard to Guile performance having a bright future. :-)

Go for it!

> Taylan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: In support of guile-emacs

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

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

On the other hand, that work has a lousy bus factor.  Here is the first
page of recent commits on GUILE's master branch:

Mark H Weaver Fix typo in CPS conversion.
Andy Wingo Minor CPS documentation cleanups
Andy Wingo Update CPS language documentation
Andy Wingo Remove unused (language tree-il inline) module.
Mark H Weaver Allow decoding of UTF-8 containing U+FFFD, the replacement character.
Andy Wingo Add closure effects
Andy Wingo Better codegen for $values terms that don't shuffle
Andy Wingo Loop peeling
Andy Wingo solve-flow-equations tweak
Andy Wingo Simplify rotate-loops.scm
Andy Wingo Loop inversion with multiple exits
Andy Wingo Rotate comparisons down to loop back-edges
Andy Wingo Eliminate trampoline gotos when possible in compile-bytecode
Andy Wingo Small expression-effects tweak
Andy Wingo Loop-invariant code motion
Andy Wingo Move solve-flow-equations to utils
Andy Wingo Factor out compute-effects/elide-type-checks from dce.scm
Andy Wingo Add missing files
Andy Wingo Rename CPS2 to CPS
Andy Wingo Remove CPS1 language
Andy Wingo Compile CPS2 directly to bytecode
Andy Wingo Slot allocation and bytecode compilation from CPS2.
Andy Wingo Fix CPS2 compute-successors
Andy Wingo intset-intersect bugfix
Andy Wingo Fix bad return shuffles for multiply-used $kreceive conts
Andy Wingo Fix error printing some wrong-num-args backtraces
Andy Wingo More slot-allocation simplification
Andy Wingo CPS1 slot-allocation simplification
Andy Wingo Utils refactors
Andy Wingo Add intset-prev and intset-fold-right
Andy Wingo Reify primitives in CPS2
Andy Wingo Fix type/range inference for mul
Andy Wingo Remove CPS optimization passes and closure conversion
Andy Wingo Optimize first-order CPS
Andy Wingo Beta reduction over first-order CPS
Andy Wingo DCE works on first-order CPS
Andy Wingo compute-reachable-functions refactor
Andy Wingo Prepare DCE pass for first-order CPS2
Andy Wingo Enable CPS2 closure conversion
Andy Wingo CPS2 closure conversion bugfixes
Andy Wingo closure-conversion docstring tweak
Andy Wingo Wire up new closure conversion pass
Andy Wingo Add CPS2 closure conversion module
Andy Wingo Verify pass works on first-order CPS
Andy Wingo Beginnings of first-order CPS optimization
Andy Wingo Tweak intset printing
Andy Wingo CPS2 renumber works with first-order CPS
Andy Wingo Fix intset-subtract to reliably produce empty-intset
Andy Wingo intset-union fast paths
Andy Wingo Reorganizing of intset/intmap helper functions
Andy Wingo Add split-rec pass
Andy Wingo Renumber before contifying to eliminate stale conts

Emacs's master branch looks a bit more diverse in authorship and less
back-and-forth in content.

Even if I only look at lisp/emacs-lisp/byte-compile.el (since it would
be unfair to take all of Emacs, a diverse application pool, as
comparison to a language):

Paul Eggert Fix a few problems with directed quotes
Paul Eggert Backslash cleanup in Elisp source files
Paul Eggert Revert some stray curved quotes I missed earlier
Paul Eggert Go back to grave quoting in source-code docstrings etc.
Stefan Monnier Fix disassembly of non-compiled lexical functions (bug#21377)
Paul Eggert Treat “instead” strings as docstrings
Paul Eggert Prefer directed to neutral quotes
Paul Eggert More-conservative ‘format’ quote restyling
Paul Eggert text-quoting-style in emacs-lisp diagnostics
Glenn Morris Address a compilation warning.
Glenn Morris Address some compilation warnings.
Paul Eggert Don't quote nil and t in doc strings
Glenn Morris Minor declare-function improvement
Artur Malabarba * lisp/emacs-lisp/bytecomp.el: Revert "Silence noninteractive compilations"
Artur Malabarba * lisp/emacs-lisp/bytecomp.el: Use `inhibit-message'
Artur Malabarba * lisp/emacs-lisp/bytecomp.el: Silence noninteractive compilations
Artur Malabarba Speed up byte-compilation and autoload generation by avoiding mode-hooks
Stefan Monnier * lisp/emacs-lisp/cl-macs.el (cl-defstruct): Keep type=nil by default.
Stefan Monnier Add (:documentation <form>) for dynamically-generated docstrings
Paul Eggert Don't downcase system diagnostics' first letters
Stefan Monnier lisp/emacs-lisp/eieio*.el: Rewrite our generics on top of cl-generic
Paul Eggert Less 'make' chatter in batch mode
Paul Eggert Update copyright year to 2015
Paul Eggert Spelling fixes
Stefan Monnier * lisp: Prefer inlinable functions to macros.
Stefan Monnier Fix bootstrap failure after last change to eval-and-compile.
Glenn Morris * bytecomp.el (byte-compile-report-error): Allow the argument to be a string. Due to the vague doc, it was already being used this way.
Stefan Monnier * lisp/emacs-lisp/bytecomp.el: Add a warning and remove a spurious warning. (byte-compile-initial-macro-environment): Don't compile before eval in `eval-and-compile'. (byte-compile-arglist-warn): Add check for defining macros after their first use.  Check call use even if the function is fboundp.
Stefan Monnier * lisp/emacs-lisp/bytecomp.el (byte-compile--use-old-handlers): Change default.
Stefan Monnier * lisp/emacs-lisp/bytecomp.el: Require cl-extra. * lisp/emacs-lisp/cl-extra.el: Add missing provide.
Stefan Monnier * lisp/select.el: Use lexical-binding. (gui-set-selection): Provide an implementation for non-GUI frames. * lisp/term/x-win.el: Use lexical-binding. (x-clipboard-yank): Fix up missed renamings. * lisp/term/w32-win.el (libgif-version, libjpeg-version): Silence compiler. (w32--set-selection): Fix up var names. * lisp/term/pc-win.el: Use lexical-binding. (w16-selection-exists-p): Silence compiler warning. (w16-selection-owner-p): Fix up missed renamings.
Stefan Monnier * lisp/emacs-lisp/bytecomp.el (byte-compile-and-folded): Optimize case where all args are copyable. (=, <, >, <=, >=): Re-enable the optimization.
Stefan Monnier Restore temporarily reverted bytecomp change
Glenn Morris Temporarily revert previous bytecomp change
Stefan Monnier * lisp/emacs-lisp/bytecomp.el (=, <, >, <=, >=): Don't optimize multi-arg case.
Stefan Monnier * lisp/subr.el (track-mouse): New macro. * lisp/emacs-lisp/cconv.el (cconv-convert, cconv-analyse-form): Remove track-mouse case. * lisp/emacs-lisp/bytecomp.el (byte-compile-track-mouse): Remove. * src/keyboard.c (track-mouse): Rename to internal--track-mouse. Make it into a function and change arg to be a function.
Stefan Monnier * lisp/emacs-lisp/bytecomp.el (byte-compile-lambda): Don't add fundoc usage for functions with no arguments.
Daniel Colascione Minor bytecomp.el fixes
Daniel Colascione Correctly treat progn contents as toplevel forms when byte compiling
Glenn Morris Move some help functions from help-fns.el to help.el, which is preloaded.
Glenn Morris Replace "Maintainer: FSF" with the emacs-devel mailing address
Glenn Morris "Use instead" obsolescence messages should end with "."
Juanma Barranquero Silence byte-compiler warning.
Daniel Colascione Use whole file-name-history'.
Stefan Monnier * lisp/abbrev.el (define-abbrev): Beware new meaning of fboundp. * lisp/emacs-lisp/elint.el (elint-find-builtins): * lisp/emacs-lisp/eldoc.el (eldoc-symbol-function): * lisp/emacs-lisp/bytecomp.el (byte-compile-callargs-warn) (byte-compile-file-form-defmumble, byte-compile, byte-compile-form): * lisp/emacs-lisp/byte-opt.el (byte-compile-inline-expand): * lisp/apropos.el (apropos-safe-documentation): * lisp/subr.el (symbol-file): Remove redundant fboundp. * lisp/progmodes/idlw-shell.el (idlwave-shell-comint-filter): Use defalias.
Paul Eggert Update copyright year to 2014 by running admin/update-copyright.


-- 
David Kastrup

Re: In support of guile-emacs

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

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

There is no question that everything that can be done independently of
Emacs can also be done inside of Emacs.

If someone does it.  The point of decoupling work on Emacs from work on
the compiling techniques within Emacs is to get more work done from the
total set of people than if everybody reinvents and designs and
maintains his own wheels.

-- 
David Kastrup

Re: In support of guile-emacs

[Tom]

Christopher Allan Webber <cwebber <at> dustycloud.org> writes:

> 
> There's been a lot of conversation on this list that's been discussing
> whether or not the Guile port of emacs could be a good basis. 

A purely theoretical question: how well defined is the interface
between elisp and the underlying core? Is there some specification 
or an automated test suite against which an implementation on top of
a new VM can be implemented? 

Or is it purely a trial and error process? Implement Elisp
on top of a VM and see if something breaks, and that's your test suite?

Re: In support of guile-emacs

[Andreas Schwab]

Tom <adatgyujto@gmail.com> writes:

> A purely theoretical question: how well defined is the interface
> between elisp and the underlying core? Is there some specification 
> or an automated test suite against which an implementation on top of
> a new VM can be implemented? 

The only defined interface are the bytecode ops.  For everything else
any functionality can move from C to Lisp and vice versa any time.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: In support of guile-emacs

[Tom]

Andreas Schwab <schwab <at> suse.de> writes:

> 
> The only defined interface are the bytecode ops.  For everything else
> any functionality can move from C to Lisp and vice versa any time.
> 

Thanks. So you have practically two interfaces: the bytecode ops and
the "standard library" which is specified in the docs, but
it's not testable (no test suite AFAIK).