From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Mon, 6 Jun 2022 12:13:07 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000025349a05e0c9c097" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39038"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 06 19:03:06 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyG8A-0009rn-Lh for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 19:03:06 +0200 Original-Received: from localhost ([::1]:59964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyG89-00026U-4q for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 13:03:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyFM7-0006fa-NT for emacs-devel@gnu.org; Mon, 06 Jun 2022 12:13:27 -0400 Original-Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:42674) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nyFM5-0000Ro-HJ for emacs-devel@gnu.org; Mon, 06 Jun 2022 12:13:27 -0400 Original-Received: by mail-lj1-x231.google.com with SMTP id a23so16286992ljd.9 for ; Mon, 06 Jun 2022 09:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UHQ8KZuX1KWpTzhEtdCXDNpWELme0o3z3N8E+G9gUVo=; b=cY8T3s+Kz0bAmI/NlkcnKtqTxY2loiKQNX1XZzYxDUNaMw3UjxmGiSjJxLUsZBXUfg q/GA+TmF0k63j/NIUkmR42NgaMx3uoDUQ9nPuUAnbgkrtuOvHm5B0d0e0qFRdtAlk5oR GF/IMwpqbwCLHt506Z1PFEh8wxigWUo9fkZ4wCpkQwqiWsI4SAbflaYQG7kD7qTH3p2G t3ING/Afc4phHuzT/ba6h1hOAI4g018yjN7TCbmY/jcLRq7wJFqVrQ+/l8imWUJoTmj/ J2TIEVgFWe86/Bj3pd5dWLkO3gTtldQHf2KYPoiRmaq6aPs7JIGOWazPwE6Rftv6qLI2 kWuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UHQ8KZuX1KWpTzhEtdCXDNpWELme0o3z3N8E+G9gUVo=; b=TlDHG65/BLoEMXtthb2ETgTgVWorMdyEx1YRWtxO5elU1nR51px0RkkicljhyWP8PK CWW7r+gFCUcAA7z6Pa21+TK2a8Ew8xfS+l1Jk2YRv4L2zqRqf1xyE+LNr6vhn7unEIph ZJLCIODvwM9GlfHq1RZUAXle+jUqZuafkBXRUuu+4dTYfSYzEG+WLanyNNdztnTCDLKG jVGrH+0DZ+u7QyslTtNM8HzPB+5qW2IKvQMc4DyIhK6G0I7hMhct54UgHH06Yig2Z2HN zmjkmz0ZiiNIGtSV0jtaW8wdiJxFGWLY4BwQ7ZZ9ObdPii0LwWFd51kIwR2BYjSlfOv7 /scg== X-Gm-Message-State: AOAM533uFLEFCIXav1l1JTt36Cmkj2V0xlZDaBCc3jPl97OsqfJjFQgS plvKKgclg0i3A7kKdMzBfgCLYvqJXT2aQFmlnYU= X-Google-Smtp-Source: ABdhPJyVSEoiGcYrJOjQCWNGoBYGxIGsoOT+O4uYi7SjmX0/RJTuHjaNYq9pOkksizyh05Aq8DrnMiS+s5JK8Hioq6s= X-Received: by 2002:a2e:9c0c:0:b0:24e:e2e0:f61e with SMTP id s12-20020a2e9c0c000000b0024ee2e0f61emr52399617lji.75.1654532000263; Mon, 06 Jun 2022 09:13:20 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::231; envelope-from=owinebar@gmail.com; helo=mail-lj1-x231.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 06 Jun 2022 12:58:29 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:290810 Archived-At: --00000000000025349a05e0c9c097 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 6, 2022 at 2:12 AM Stefan Monnier 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 --00000000000025349a05e0c9c097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

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

Yes, I agree.=C2=A0 As I wrote in the initial email, = my questions are primarily=C2=A0
curiosity=C2=A0about how the new= capability can be further exploited.=C2=A0 When I'm not=C2=A0
loading the build down with a ridiculous number of packages, it performs = very well.
=C2=A0
> True, but it does lead to a little more disappointment when that 2.5-5= x
> 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 ar= ticles I read when I first learned=C2=A0
about this new capabilit= y.=C2=A0 It was in the context of overall emacs performance=C2=A0
with the feature enabled, rather than any particular piece of code.
<= div>=C2=A0=C2=A0
> Sorry, no.=C2=A0 I meant I'm curious if having them in the user= 9;s cache versus
> the system ELN cache would make any difference in start-up time, ignor= ing
> the initial async native compilation.=C2=A0 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 perfo= rmance 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.=C2=A0 Bolting some existing = GC
onto Emacs won't be easy, tho.

Chro= mium came to mind primarily because I've been tracking V8's refacto= ring=C2=A0
of the "Oilpan" gc for use as a stand-alone = collector for other projects I'm interested in.
Though I beli= eve V8 uses a type-tagging system treated specially by the collector separa= tely
from the C++ classes managed by the stand-alone collector.= =C2=A0 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 mon= key's
collector a few years ago (2017 I believe) into emacs a= s a proof of concept. My very cursory
inspection of the memory al= location bits of the emacs core give me the impression the abstraction
boundaries set by the simple interface are not rampantly violated.=C2= =A0 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 eli= gible for incorporation into emacs directly, given
the legal requ= irements for explicit copyright assignment.=C2=A0 Maybe the best bet would = be to define a=C2=A0
rigorous interface and allow alternative GC = implementations to be plugged in.=C2=A0 That would make it easier
to experiment with alternative garbage collectors more generally,=C2=A0 wh= ich would probably be a general positive
if you were looking to i= mprove that part of the system in general while maintaining the current saf= e implementation.

Lynn

--00000000000025349a05e0c9c097--