[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: native compilation units
From: |
Stefan Monnier |
Subject: |
Re: native compilation units |
Date: |
Wed, 15 Jun 2022 08:23:45 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
> The fact that cl-flet (and cl-labels) are defined to provide immutable
> bindings is really a surprise to me.
Whether they are mutable or not is not directly relevant, tho: the
import part is that being lexically scoped, the compiler gets to see all
the places where it's used and can thus determine that it's
ever mutated.
> There is one kind of expression where Andrea isn't quite correct, and that
> is with respect to (eval-when-compile ...).
You don't need `eval-when-compile`. It's already "not quite correct"
for lambda expressions. What he meant is that the function associated
with a symbol can be changed in every moment. But if you call
a function without going through such a globally-mutable indirection the
problem vanishes.
> Now the optimizer can treat ct-r1,ct-r2, and ct-r3 as constants for the
> purpose of propagation,
Same holds for
(let* ((a (lambda (f) (lambda (x) (f (+ x 5)))))
(b (lambda (y) (* y 3)))
(f (funcall a b)))
(lambda (z)
(pow z (funcall f 6))))
>> It's also "modulo enough work on the compiler (and potentially some
>> primitive functions) to make the code fast".
> Absolutely, it just doesn't look to me like a very big lift compared to,
> say, what Andrea did.
It very depends on the specifics, but it's definitely not obviously true.
ELisp like Python has grown around a "slow language" so its code is
structured in such a way that most of the time the majority of the code
that's executed is actually not ELisp but C, over which the native
compiler has no impact.
> Does this mean the native compiled code can only produce closures in
> byte-code form?
Not directly, no. But currently that's the case, yes.
> below with shared structure (the '(5)], but I don't see anything in
> the printed text to indicate it if read back in.
You need to print with `print-circle` bound to t, like the compiler does
when writing to a `.elc` file.
> I'm sure you're correct in terms of the current code base. But isn't
> the history of these kinds of improvements in compilers for functional
> languages that coding styles that had been avoided in the past can be
> adopted and produce faster code than the original?
Right, but it's usually a slow co-evolution.
> In this case, it would be enabling the pervasive use of recursion and
> less reliance on side-effects.
Not everyone would agree that "pervasive use of recursion" is an improvement.
> Improvements in the gc wouldn't hurt, either.
Actually, nowadays lots of benchmarks are already bumping into the GC as
the main bottleneck.
> ** The 'lexical-binding' local variable is always enabled.
Indeed, that's misleading. Not sure how none of us noticed it before.
Stefan
- Re: native compilation units, (continued)
- Re: native compilation units, Andrea Corallo, 2022/06/08
- Re: native compilation units, Lynn Winebarger, 2022/06/11
- Re: native compilation units, Stefan Monnier, 2022/06/11
- Re: native compilation units, Lynn Winebarger, 2022/06/11
- Re: native compilation units, Stefan Monnier, 2022/06/11
- Re: native compilation units, Lynn Winebarger, 2022/06/12
- Re: native compilation units, Stefan Monnier, 2022/06/12
- Re: native compilation units, Lynn Winebarger, 2022/06/13
- Re: native compilation units, Stefan Monnier, 2022/06/13
- Re: native compilation units, Lynn Winebarger, 2022/06/14
- Re: native compilation units,
Stefan Monnier <=
- Re: native compilation units, Lynn Winebarger, 2022/06/19
- Re: native compilation units, Stefan Monnier, 2022/06/19
- Re: native compilation units, Lynn Winebarger, 2022/06/19
- Re: native compilation units, Lynn Winebarger, 2022/06/20
- Re: native compilation units, Lynn Winebarger, 2022/06/20
- Re: native compilation units, Lynn Winebarger, 2022/06/25
- Re: native compilation units, Lynn Winebarger, 2022/06/26
- Re: native compilation units, Andrea Corallo, 2022/06/08