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: Fri, 3 Jun 2022 10:17:25 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c479d005e08bc844" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 03 17:20:56 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 1nx96d-00080v-H2 for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jun 2022 17:20:55 +0200 Original-Received: from localhost ([::1]:55826 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nx96b-0005gY-NB for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jun 2022 11:20:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nx87R-00022b-S6 for emacs-devel@gnu.org; Fri, 03 Jun 2022 10:17:41 -0400 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:43953) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nx87P-0001VM-SF for emacs-devel@gnu.org; Fri, 03 Jun 2022 10:17:41 -0400 Original-Received: by mail-lj1-x232.google.com with SMTP id o15so8560020ljp.10 for ; Fri, 03 Jun 2022 07:17:38 -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=90iWv/8VIbA4F+oF4ALdgCWs+kTfBQbMCnwSWYALtZ4=; b=TtErIBYF756khwe9MlztWcSM6blr80Ci7tgPdg1kHOwoXdObp1NddNjw+Fe5wKqHWw juTVQiGhkdqJ2wlq97RDYmT+OcoIzoSCqUTV/grRtvr88cjRIZpwKKw4hs/012ZOa5yP Fha7Xpv9T9KR9iCITS8b8PsAfUVnVm9ucF/iLMW5ShdOj390mybuYblpMXeXmJi57uMH MXrixaM89hhJLuLboPs+6Vwl9wvoqyauOBD2wQ8DBVfx+4Koq4ALHW7EThaRoTb7RAnR z2u6ZMr2M2GlltVvJx2NgNjaZ5dzt1dH2i12gedDOgvQxnrvFV27GpgG6iGx+UsUmzKU /vcA== 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=90iWv/8VIbA4F+oF4ALdgCWs+kTfBQbMCnwSWYALtZ4=; b=omKBlxg+EWcZAUiIag15evrxrizvuUibwezafXQG1BkC5iCcET+TIbleTbarXlqOLL FGdTcMTxzhuosURU1r6FXGF3hAEyQy+nU2cXCslFLcrCHs7ZB0DTRDY9K7gG1YDGhMZu 8eLSYY/tMivOupq7fLTjbYMXRlwmvxKN3/P7uBjcqKveFq7B8y+410pwh4tUnkdhBwVX 8i385yMgx/OOdpZ1QHcIkVtGbBp/HwsH98m7g4D4aJZvfMfJ//l1ShLgNP2DO/tf4d8W Ov0cU/d+dYZHx+zVz8hisyBdydon06GqBfMIAS6Vq0icgNs4boPQE0d4n4R47NtLyyzP HAhg== X-Gm-Message-State: AOAM530yGhE/R8mWPYFlJw7rHQKvsRCO6X30JFvXgYF1ovqpXU2RdGIJ PKrFW7geF4f3KOes8GNoVI2uyJzOyJuzhDUmT7OB8S9p X-Google-Smtp-Source: ABdhPJyoIuS7CrlNgujynVDhJKKuwycqhoU/yeufO2c4JZQ977MWvhT1Qn0xs/bGwn5X9hm8pMkPCaeDLblSJkbvsHw= X-Received: by 2002:a2e:824e:0:b0:253:e2ee:f534 with SMTP id j14-20020a2e824e000000b00253e2eef534mr39473702ljh.186.1654265856947; Fri, 03 Jun 2022 07:17:36 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::232; envelope-from=owinebar@gmail.com; helo=mail-lj1-x232.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: Fri, 03 Jun 2022 11:19:31 -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:290631 Archived-At: --000000000000c479d005e08bc844 Content-Type: text/plain; charset="UTF-8" Thanks. There was a thread in January starting at https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01005.html that gets at one scenario. At least in pre-10 versions in my experience, Windows has not dealt well with large numbers of files in a single directory, at least if it's on a network drive. There's some super-linear behavior just listing the contents of a directory that makes having more than, say, a thousand files in a directory impractical. That makes packaging emacs with all files on the system load path precompiled inadvisable. If you add any significant number of pre-compiled site-lisp libraries (eg a local elpa mirror), it will get worse. Aside from explicit interprocedural optimization, is it possible libgccjit would lay out the code in a more optimal way in terms of memory locality? If the only concern for semantic safety with -O3 is the redefinability of all symbols, that's already the case for emacs lisp primitives implemented in C. It should be similar to putting the code into a let block with all defined functions bound in the block, then setting the global definitions to the locally defined versions, except for any variations in forms with semantics that depend on whether they appear at top-level or in a lexical scope. It might be interesting to extend the language with a form that makes the unsafe optimizations safe with respect to the compilation unit. On Wed, Jun 1, 2022 at 9:50 AM Andrea Corallo wrote: > Lynn Winebarger writes: > > > Hi, > > Since the native compiler does not support linking eln files, I'm > curious if anyone has tried combining elisp files as > > source code files and compiling the result as a unit? > > Has there been any testing to determine if larger compilation units > would be more efficient either in terms of loading or > > increased optimization opportunities visible to the compiler? > > Hi, > > the compiler can't take advantage of interprocedural optimizations (such > as inline etc) as every function in Lisp can be redefined in every > moment. > > You can trigger those optimizations anyway using native-comp-speed 3 but > each time one of the function in the compilation unit is redefined > you'll have to recompile the whole CU to make sure all changes take > effect. > > This strategy might be useful, but I guess limited to some specific > application. > > Best Regards > > Andrea > --000000000000c479d005e08bc844 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks.
There was a= thread in January starting at=C2=A0https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01= 005.html that gets at one scenario.=C2=A0 At least in pre-10 versions i= n my experience, Windows has not dealt well with large numbers of files in = a single directory, at least if it's on a network drive.=C2=A0 There= 9;s some super-linear behavior just listing the contents of a directory tha= t makes having more than, say, a thousand files in a directory impractical.= =C2=A0 That makes packaging emacs with all files on the system load path pr= ecompiled inadvisable.=C2=A0 If you add any significant number of pre-compi= led site-lisp libraries (eg a local elpa mirror), it will get worse.
<= div dir=3D"auto">
Aside from explicit interproce= dural optimization, is it possible libgccjit would lay out the code in a mo= re optimal way in terms of memory locality?

If the only concern for semantic safety with -O3 is the redefinabili= ty of all symbols, that's already the case for emacs lisp primitives im= plemented in C.=C2=A0 It should be similar to putting the code into a let b= lock with all defined functions bound in the block, then setting the global= definitions to the locally defined versions, except for any variations in = forms with semantics that depend on whether they appear at top-level or in = a lexical scope.=C2=A0 It might be interesting to extend the language with = a form that makes the unsafe optimizations safe with respect to the compila= tion unit.



On Wed, Jun 1, 2022 at 9:50 AM Andrea Corallo <akrl@sdf.or= g> wrote:
Lynn Winebarger <owinebar@gmail.com> writes:

> Hi,
> Since the native compiler does not support linking eln files, I'm = curious if anyone has tried combining elisp files as
> source code files and compiling the result as a unit?
> Has there been any testing to determine if larger compilation units wo= uld be more efficient either in terms of loading or
> increased optimization opportunities visible to the compiler?

Hi,

the compiler can't take advantage of interprocedural optimizations (suc= h
as inline etc) as every function in Lisp can be redefined in every
moment.

You can trigger those optimizations anyway using native-comp-speed 3 but each time one of the function in the compilation unit is redefined
you'll have to recompile the whole CU to make sure all changes take
effect.

This strategy might be useful, but I guess limited to some specific
application.

Best Regards

=C2=A0 Andrea
--000000000000c479d005e08bc844--