Re: native compilation units

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Hmm... I count a bit over 6K ELisp files in Emacs + (Non)GNU ELPA, so
the ELN cache should presumably not go much past 10K files.

Performance issues with read access to directories containing less than
10K files seems like something that was solved last century, so
I wouldn't worry very much about it.

[ But that doesn't mean we shouldn't try to compile several ELisp files
  into a single ELN file, especially since the size of ELN files seems
  to be proportionally larger for small ELisp files than for large
  ones.  ]

> Aside from explicit interprocedural optimization, is it possible libgccjit
> would lay out the code in a more optimal way in terms of memory locality?

Could be, but I doubt it because I don't think GCC gets enough info to
make such a decision.  For lazily-compiled ELN files I could imagine
collecting some amount of profiling info to generate better code, but
our code generation is definitely not that sophisticated.

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

Not really:
- Most ELisp primitives implemented in C can be redefined just fine.
  The problem is about *calls* to those primitives, where the
  redefinition may fail to apply to those calls that are made from C.
- While the problem is similar the scope is very different.

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

IIUC the current native-compiler will actually leave those
locally-defined functions in their byte-code form :-(

IOW, there are lower-hanging fruits to pick first.

> It might be interesting to extend the language with a form that
> makes the unsafe optimizations safe with respect to the compilation unit.

Yes, in the context of Scheme I think this is called "sealing".


        Stefan