Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie <acm@muc.de>]

Hello, Óscar.

On Mon, Apr 26, 2021 at 22:02:49 +0200, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> C code is opaque to native-comp and puts a hard limit on how much it can
> >> optimize Elisp. Thus I hope that in the future more and more code will
> >> be moved from C to Elisp.

> > Does that make sense?  To move time critical code from fast C to slow
> > Lisp, and then optimise it back, partly?

> Calling C is a bit slow, but that's not the worst problem it introduces.
> When a call to a C function is made, the native-comp optimizer must
> throw away information it learned about the Elisp code it was compiling,
> hence reducing optimization opportunities. Furthermore, the C function
> must know how to many cases while only one or a few of them make sense
> at any given call site.

You're suggesting optimisation between Lisp functions.  I'm sceptical
about how much that could win.

> Consider this extreme example:

> (defun foo (x)
>   (+ x 12))
  
> (defun the-answer-p (x)
>   (or (and (stringp x) (string= x "42"))
>       (and (numberp x) (= x 42))
>       (and (bufferp x) ... etc)))

> (let ((a 30))
>   (if (the-answer-p (foo a))
>       (message "The answer is %d" (foo a))
>     (message "We remain ignorant")))

> The optimizer knows that the argument passed to `foo' is `a', which
> holds the constant `30'. It also knows that the value returned by `foo'
> only depends on its argument, so it can simply replace those calls to
> `foo' with (+ 30 12), and then with its result: 42. Then, on the call to
> `the-answer-p', the optimizer knows that the argument is the numeric
> constant 42, hence the second condition is true, so it can replace
> `(the-answer-p (foo a))' with `true', and then colapse the `if' to just

> (message "The answer is %d" 42)

This sort of thing is surely untypical in Emacs.

> If `foo' and `the-answer-p' were implemented on C, none of this
> optimizations could be possible, because the optimizer would know
> nothing about the inner workings of those functions.

> I'm no Elisp expert, so the above might not fully translate to what is
> achievable in practice by native-comp, but the general point holds.

> >> And other areas can benefit too: one thing which IMO has lots of
> >> potential is to native-compile regexps.

> > Again, how would that work?  Regexps are already handled in C.  How
> > could native compilation of Lisp add anything?

> Not native compilation of Elisp, but native compilation of the regexps:
> a function is generated that implements the regexp. Instead of passing
> the regexp to the engine, the function is called.

OK, I see what you mean, now.  Currently, if I understand correctly,
regexps are compiled into an interpreted language at runtime, and they
are stored in a (fairly large) cache indexed by the regexp string.

When would you compile the regexps into native code?  For constant
regexps this can be done at build time, but there are regexps
constructed at run time in Emacs.  This compilation of regexps at run
time might negate the advantages in speed that the complation would
otherwise bring.

-- 
Alan Mackenzie (Nuremberg, Germany).