Re: native compilation units

[Lynn Winebarger <owinebar@gmail.com>]

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

On Mon, Jun 6, 2022 at 2:12 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

>
> 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.
>
> Yes, I agree.  As I wrote in the initial email, my questions are primarily
curiosity about how the new capability can be further exploited.  When I'm
not
loading the build down with a ridiculous number of packages, it performs
very well.


> > 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's a good question - it was one of the articles I read when I first
learned
about this new capability.  It was in the context of overall emacs
performance
with the feature enabled, rather than any particular piece of code.


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

Chromium came to mind primarily because I've been tracking V8's refactoring
of the "Oilpan" gc for use as a stand-alone collector for other projects
I'm interested in.
Though I believe V8 uses a type-tagging system treated specially by the
collector separately
from the C++ classes managed by the stand-alone collector.  That's the
piece I think would
be adapted for lisp GC, with the added benefit of offering integrated GC
for types using the
cppgc interface for additional modules.

I did see a thread in the archives of emacs-devel that someone hacked
spider monkey's
collector a few years ago (2017 I believe) into emacs as a proof of
concept. My very cursory
inspection of the memory allocation bits of the emacs core give me the
impression the abstraction
boundaries set by the simple interface are not rampantly violated.  I would
hope that at this
point adapting the V8 (or similar) collector would be more straightforward
than that effort was.

I'm also not sure whether code derived from V8 would be eligible for
incorporation into emacs directly, given
the legal requirements for explicit copyright assignment.  Maybe the best
bet would be to define a
rigorous interface and allow alternative GC implementations to be plugged
in.  That would make it easier
to experiment with alternative garbage collectors more generally,  which
would probably be a general positive
if you were looking to improve that part of the system in general while
maintaining the current safe implementation.

Lynn

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