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

["Óscar Fuentes" <ofv@wanadoo.es>]

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.

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)

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.