Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium

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

> None of that applies to a compiler.  Any compiler that transforms Emacs Lisp
> into something else must be able to deal with dynamic binding.

AFAIK it does *handle* such code (i.e. such code will run correctly), it
just doesn't optimize it (in this particular case it keeps it in `.elc` form).

> So there is no reason it should have trouble with dynamic binding
> mode, that only means it is not finished.

That's partly right.  But then again, there's always something else that
can be optimized.  You have to prioritize.  I think it's perfectly OK to
say that if you want higher performance you should start by adapting
your Elisp/d code to Elisp/l, especially since the compiler will be able
to do a much better job with Elisp/l than Elisp/d since when compiled
via libggcjit, a lexical variable will turn into (more or less) a plain
normal C variable whereas a dynamic variable will only be accessed via
the standard `symbol-value`, `set`, ... accessors.  For this reason, on
Elisp/d the native compiler won't be able to get much more speed up than
that resulting from removing the while+switch interpretive overhead,
whereas on Elisp/l it can go significantly further by allocating
variables to registers, removing type tests, boxing/unboxing pairs, ...


        Stefan