Re: On elisp running native

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> [ I wasn't able to follow all the explanations at
>>   http://akrl.sdf.org/gccemacs.html, such as the one around "function
>>   frames", with which I'm not familiar.  Are these like activation
>>   frames? ]
> Yes I think we both mean the same.  In this case basically where we store
> automatic variables and data related to the single activated function.

OK, thanks.  I think "activation frame" is the standard term (of which
there can be several on the stack at the same time in case of recursion).

>> - How did you get there?  I see some "we" in the web page, which makes
>>   it sound like you weren't completely alone.
> Sorry for that I'm not much into using 'I'.

That's OK, but I see you tried to use it as a clever ploy to dodge the
initial question: how did you get there?

>> - Have you tried to use the compiler as benchmark (i.e. how much faster
>>   can Emacs compile (either byte-compile or native-compile)) if the
>>   compiler code is native-compiled (since it's all using
>>   lexical-binding already)?
> I use the compiler native compiled but because of the previous point I
> think is hard to measure the difference.

How 'bout measuring the time to byte-compile a given set of files, then:
first using the byte-compiled compiler and then using the
native-compiled compiler (where "compiler" here means at least cconv.el,
byte-opt.el, bytecomp.el, and macroexp.el)?

BTW, I think developing a good set of Elisp benchmarks is useful
independently from this, so I'd encourage you to submit your benchmarks
as a new GNU ELPA package (we could also incorporate it into Emacs
itself, but I think we'll want to use it to compare performance between
diverse Emacsen, so a separate package makes more sense).

Maybe someone from the Gnus side will want to submit more benchmarks
(such as one that manipulates "sets/ranges or article numbers").

> Talking about compile time in general I think we are looking at
> something like few minutes to compile the whole Emacs at speed 0.  The
> time goes up to say ~4 hours with 4 cores for the same job at speed 2.

[ Compile time varies for me with the normal Emacs from less than
  5 minutes to more than an hour depending on the machine on which
  I compile, so absolute times don't speak to me very much.  ]
  
So, IIUC, with enough optimisations enabled, we gets into "a long
time" territory?

> I think it will be interesting to look into the gcc compilation pipe to
> see where we are losing so much time, my guess is that there's one or
> few passes that go a little nuts with all the moves we do.  I had no
> time to look into it but my guess is that once understood the problem we
> can probably dime it down.

Indeed, I'm surprised that compilation time in gcc would blow up by
significantly more than a factor 10 just because of optimisation
options, so either we're using optimisations which are really too
costly, or there should be something we can do to avoid this blow up
without any significant performance loss.


        Stefan