all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Lynn Winebarger <owinebar@gmail.com>
Cc: Andrea Corallo <akrl@sdf.org>,  emacs-devel@gnu.org
Subject: Re: native compilation units
Date: Mon, 06 Jun 2022 02:12:30 -0400	[thread overview]
Message-ID: <jwvilpemizt.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CAM=F=bChvmO_GZsnH+Qr1e93ogLPNad6AOAYcwU=wNdPKcFg1w@mail.gmail.com> (Lynn Winebarger's message of "Mon, 6 Jun 2022 00:12:29 -0400")

> Not sure if these general statistics are of much use, but of 4324 source
> files successfully compiled (1557 from the lisp directory), with a total
> size of 318MB, including 13 trampolines,
> The smallest 450 are 17632 bytes or less, with the trampolines at 16744
> bytes, total of 7.4M
> The smallest 1000 are under 25700 bytes, totaling 20M
> The smallest 2000 are under 38592 bytes, totaling 48M
> The smallest 3000 are under 62832 bytes, totaling 95M
> The smallest 4000 are under 188440 bytes, totaling 194M
> There are only 58 over 500k in size, and only 13 over 1M (max is 3.1M)
> Those last 58 total about 52M in size.

The way I read this, the small files don't dominate, so bundling them
may still be a good idea but it's probably not going to make
a big difference.

> I am curious as to why the system doesn't just produce trampolines for all
> the system calls AOT in a single module.

Trampolines are needed for any native-compiled function which
gets redefined.  We could try to build them eagerly when the
native-compiled function is compiled, and there could be various other
ways to handle this.  There's room for improvement here, but the current
system works well enough for a first version.

> True, but it does lead to a little more disappointment when that 2.5-5x
> speedup is dominated by the load-path length while starting up.

I don't know where you got that 2.5-5x expectation, but native
compilation will often result in "no speed up at all".

> That would explain the behavior I've seen.  If that's the case, shouldn't
> batch-native-compile produce the byte-compiled file if it doesn't exist?

Sounds about right, tho maybe there's a good reason for the current
behavior, I don't know.  Maybe you should `M-x report-emacs-bug`.

> Sorry, no.  I meant I'm curious if having them in the user's cache versus
> the system ELN cache would make any difference in start-up time, ignoring
> the initial async native compilation.  In particular whether the checksum
> calculation is bypassed in one case but not the other (by keeping a
> permanent mapping from the system load-path to the system cache, say).

No, I don't think it should make any difference in this respect.

> I'm guessing the native compiled code is making the GC's performance a more
> noticeable chunk of overhead.

Indeed, the GC is the same and the native compiler does not make many
efforts to reduce memory allocations, so fraction of time spent in GC
tends to increase.

> I'd really love to see something like Chromium's concurrent gc
> integrated into Emacs.

Our GC is in serious need of improvement, yes.  Bolting some existing GC
onto Emacs won't be easy, tho.

> If I do any rigorous experiments to see if there's anything resembling a
> virtuous cycle in larger compilation units + higher intraprocedural
> optimizations, I'll report back.

Looking forward to it, thanks,

I'd be interested as well in seeing a `profile-report` output covering
your minute-long startup.


        Stefan




  reply	other threads:[~2022-06-06  6:12 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31  1:02 native compilation units Lynn Winebarger
2022-06-01 13:50 ` Andrea Corallo
2022-06-03 14:17   ` Lynn Winebarger
2022-06-03 16:05     ` Eli Zaretskii
     [not found]       ` <CAM=F=bDxxyHurxM_xdbb7XJtP8rdK16Cwp30ti52Ox4nv19J_w@mail.gmail.com>
2022-06-04  5:57         ` Eli Zaretskii
2022-06-05 13:53           ` Lynn Winebarger
2022-06-03 18:15     ` Stefan Monnier
2022-06-04  2:43       ` Lynn Winebarger
2022-06-04 14:32         ` Stefan Monnier
2022-06-05 12:16           ` Lynn Winebarger
2022-06-05 14:08             ` Lynn Winebarger
2022-06-05 14:46               ` Stefan Monnier
2022-06-05 14:20             ` Stefan Monnier
2022-06-06  4:12               ` Lynn Winebarger
2022-06-06  6:12                 ` Stefan Monnier [this message]
2022-06-06 10:39                   ` Eli Zaretskii
2022-06-06 16:23                     ` Lynn Winebarger
2022-06-06 16:58                       ` Eli Zaretskii
2022-06-07  2:14                         ` Lynn Winebarger
2022-06-07 10:53                           ` Eli Zaretskii
2022-06-06 16:13                   ` Lynn Winebarger
2022-06-07  2:39                     ` Lynn Winebarger
2022-06-07 11:50                       ` Stefan Monnier
2022-06-07 13:11                         ` Eli Zaretskii
2022-06-14  4:19               ` Lynn Winebarger
2022-06-14 12:23                 ` Stefan Monnier
2022-06-14 14:55                   ` Lynn Winebarger
2022-06-08  6:56           ` Andrea Corallo
2022-06-11 16:13             ` Lynn Winebarger
2022-06-11 16:37               ` Stefan Monnier
2022-06-11 17:49                 ` Lynn Winebarger
2022-06-11 20:34                   ` Stefan Monnier
2022-06-12 17:38                     ` Lynn Winebarger
2022-06-12 18:47                       ` Stefan Monnier
2022-06-13 16:33                         ` Lynn Winebarger
2022-06-13 17:15                           ` Stefan Monnier
2022-06-15  3:03                             ` Lynn Winebarger
2022-06-15 12:23                               ` Stefan Monnier
2022-06-19 17:52                                 ` Lynn Winebarger
2022-06-19 23:02                                   ` Stefan Monnier
2022-06-20  1:39                                     ` Lynn Winebarger
2022-06-20 12:14                                       ` Lynn Winebarger
2022-06-20 12:34                                       ` Lynn Winebarger
2022-06-25 18:12                                       ` Lynn Winebarger
2022-06-26 14:14                                         ` Lynn Winebarger
2022-06-08  6:46         ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvilpemizt.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=akrl@sdf.org \
    --cc=emacs-devel@gnu.org \
    --cc=owinebar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.