Ahead of time compilation?

Ahead of time compilation?

[Perry E. Metzger]

Given the recent JIT discussion, it occurs to me that a large
fraction of the elisp infrastructure in the average emacs is the
stuff that gets slurped in and undumped. Perhaps all that stuff could
get ahead of time compiled before undump for performance? Build time
isn't nearly as relevant for me as speed during execution, and on
platforms that don't have the infra, the interpreter could continue
to be use for that stuff.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Ahead of time compilation?

[Tom Tromey]

>>>>> "Perry" == Perry E Metzger <perry@piermont.com> writes:

Perry> Given the recent JIT discussion, it occurs to me that a large
Perry> fraction of the elisp infrastructure in the average emacs is the
Perry> stuff that gets slurped in and undumped. Perhaps all that stuff could
Perry> get ahead of time compiled before undump for performance? Build time
Perry> isn't nearly as relevant for me as speed during execution, and on
Perry> platforms that don't have the infra, the interpreter could continue
Perry> to be use for that stuff.

See these:

https://lists.gnu.org/archive/html/emacs-devel/2018-09/msg00451.html

https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00767.html

There's also the unfinished el-compilador, which is a different
expression of this idea.

Tom

Re: Ahead of time compilation?

[Perry E. Metzger]

On Fri, 14 Sep 2018 16:25:39 -0600 Tom Tromey <tom@tromey.com> wrote:
> >>>>> "Perry" == Perry E Metzger <perry@piermont.com> writes:  
> 
> Perry> Given the recent JIT discussion, it occurs to me that a large
> Perry> fraction of the elisp infrastructure in the average emacs is
> Perry> the stuff that gets slurped in and undumped. Perhaps all
> Perry> that stuff could get ahead of time compiled before undump
> Perry> for performance? Build time isn't nearly as relevant for me
> Perry> as speed during execution, and on platforms that don't have
> Perry> the infra, the interpreter could continue to be use for that
> Perry> stuff.  
> 
> See these:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2018-09/msg00451.html
> 
> https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00767.html
> 
> There's also the unfinished el-compilador, which is a different
> expression of this idea.

I sort of meant deliberately run the JIT on *all( the elisp that gets
loaded pre-dump, and when you dump emacs, everything will be
precompiled. Or does the JIT already JIT everything that gets loaded?

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Ahead of time compilation?

[Tom Tromey]

>>>>> "Perry" == Perry E Metzger <perry@piermont.com> writes:

Perry> On Fri, 14 Sep 2018 16:25:39 -0600 Tom Tromey <tom@tromey.com> wrote:
Perry> I sort of meant deliberately run the JIT on *all( the elisp that gets
Perry> loaded pre-dump, and when you dump emacs, everything will be
Perry> precompiled. Or does the JIT already JIT everything that gets loaded?

Oh, sorry, I misunderstood.

Right now the JIT always jits everything it can.  This isn't ideal
though.  There was a subthread about this.

I like your idea.  One problem is that the portable dumper might
conflict with it.  The main issue is that the JIT, currently (there are
maybe some decisions to be made here around compiling closures) bakes in
references to objects in the constant pool.  (This is one reason that
the JIT code is stuck into the bytecode vector: it ties the lifetimes
together.)  But, with the portable dumper, objects are "reinflated" at
startup, so this wouldn't work.  (This is basically the same problem
faced by the AOT compiler.)

FWIW libjit claims to be able to write out an ELF but that isn't
actually implemented.  And anyway it isn't the main problem I think.

Tom

Re: Ahead of time compilation?

[Eli Zaretskii]

> Date: Fri, 14 Sep 2018 18:16:36 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> 
> Given the recent JIT discussion, it occurs to me that a large
> fraction of the elisp infrastructure in the average emacs is the
> stuff that gets slurped in and undumped. Perhaps all that stuff could
> get ahead of time compiled before undump for performance? Build time
> isn't nearly as relevant for me as speed during execution, and on
> platforms that don't have the infra, the interpreter could continue
> to be use for that stuff.

IMO, before we decide to do this, we should convince ourselves that
JIT in the libjit branch indeed speeds up things significantly enough
for us to bother doing the above.  There was contradictory evidence
about that in the past, see recent threads on this list.  As one data
point I measured myself, the time it took to byte-compile all of the
Lisp files in the Emacs tree was almost exactly the same with and
without JIT.

Benchmarks of JIT performance as compared to byte-compiled code are
therefore greatly appreciated.  For the issue you raise above, I guess
we should try benchmarking code that gets dumped into the Emacs
executable, from preloaded packages; you can see them listed in
loadup.el.

Thanks.

Re: Ahead of time compilation?

[Perry E. Metzger]

On Sat, 15 Sep 2018 09:57:39 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Fri, 14 Sep 2018 18:16:36 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > 
> > Given the recent JIT discussion, it occurs to me that a large
> > fraction of the elisp infrastructure in the average emacs is the
> > stuff that gets slurped in and undumped. Perhaps all that stuff
> > could get ahead of time compiled before undump for performance?
> > Build time isn't nearly as relevant for me as speed during
> > execution, and on platforms that don't have the infra, the
> > interpreter could continue to be use for that stuff.  
> 
> IMO, before we decide to do this, we should convince ourselves that
> JIT in the libjit branch indeed speeds up things significantly
> enough for us to bother doing the above.

Naturally. If it isn't actually a significant improvement there's no
point.

Perry
-- 
Perry E. Metzger		perry@piermont.com