all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Ahead of time compilation?
@ 2018-09-14 22:16 Perry E. Metzger
  2018-09-14 22:25 ` Tom Tromey
  2018-09-15  6:57 ` Eli Zaretskii
  0 siblings, 2 replies; 6+ messages in thread
From: Perry E. Metzger @ 2018-09-14 22:16 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ahead of time compilation?
  2018-09-14 22:16 Ahead of time compilation? Perry E. Metzger
@ 2018-09-14 22:25 ` Tom Tromey
  2018-09-14 23:52   ` Perry E. Metzger
  2018-09-15  6:57 ` Eli Zaretskii
  1 sibling, 1 reply; 6+ messages in thread
From: Tom Tromey @ 2018-09-14 22:25 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ahead of time compilation?
  2018-09-14 22:25 ` Tom Tromey
@ 2018-09-14 23:52   ` Perry E. Metzger
  2018-09-15  2:33     ` Tom Tromey
  0 siblings, 1 reply; 6+ messages in thread
From: Perry E. Metzger @ 2018-09-14 23:52 UTC (permalink / raw)
  To: Tom Tromey; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ahead of time compilation?
  2018-09-14 23:52   ` Perry E. Metzger
@ 2018-09-15  2:33     ` Tom Tromey
  0 siblings, 0 replies; 6+ messages in thread
From: Tom Tromey @ 2018-09-15  2:33 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: Tom Tromey, emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ahead of time compilation?
  2018-09-14 22:16 Ahead of time compilation? Perry E. Metzger
  2018-09-14 22:25 ` Tom Tromey
@ 2018-09-15  6:57 ` Eli Zaretskii
  2018-09-15 21:33   ` Perry E. Metzger
  1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2018-09-15  6:57 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ahead of time compilation?
  2018-09-15  6:57 ` Eli Zaretskii
@ 2018-09-15 21:33   ` Perry E. Metzger
  0 siblings, 0 replies; 6+ messages in thread
From: Perry E. Metzger @ 2018-09-15 21:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-09-15 21:33 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-09-14 22:16 Ahead of time compilation? Perry E. Metzger
2018-09-14 22:25 ` Tom Tromey
2018-09-14 23:52   ` Perry E. Metzger
2018-09-15  2:33     ` Tom Tromey
2018-09-15  6:57 ` Eli Zaretskii
2018-09-15 21:33   ` Perry E. Metzger

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.