Re: native compilation units

[Lynn Winebarger <owinebar@gmail.com>]

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

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 <akrl@sdf.org> 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
> 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
>

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