Re: Blockers for Guile 2.2

[Luca Fascione]

Jean,
how many times did you run these tests?
Eyeballing your numbers it seems there's effectively no difference in
execution time opt/no-opt and 2.2/3.0.
Is the 5% a stable figure, or is it just a one-sample thing?

Would it be a passable inference that the reason the optimizer has
effectively no measurable impact in either runtime
is that the scheme source code runs are comparatively short and contain
large amounts of code the optimizer can't change?
I'm imagining that if your source is largely an alternation of scheme
language built-ins (or scheme library code)
interspersed with fairly frequent calls into lilypond's brain, the
optimizer can't do much about the latter.
At the same time, you might be sitting in front of gains coming from making
these API calls more efficient,
which could be interesting (albeit largely orthogonal to the discussion at
hand). I'm not sure how division of cost works out,
if there is overhead in preparing for invoking the callbacks vs executing
them, for example. I guess insight in that
could help focus effort, if any was warranted.

I thought the -O0 compilation time in Guile 3.0 was _really_ cool, I guess
it indicates the front-end of the
3.x compiler is vastly more efficient? Seems like it could be an
interesting way forward for the dev group to run
3.x with -O0 for iteration cycles, and then do what David is saying to ship
the scm file with optimizations on
and have the in-score Scheme be just built -O0.

Reading briefly the message you posted, it seems -O1 might be a better way
to go still, which might regain
a teeny tiny bit of speed at a potentially very modest cost (say even if
your 3.5s become 4 or 5, you still come out
with a net win compared to 2.2's 20s).

I agree these results are a very cool finding.

L

On Sat, Feb 26, 2022 at 2:47 PM Jean Abou Samra <jean@abou-samra.fr> wrote:

> Le 26/02/2022 à 13:51, Han-Wen Nienhuys a écrit :
> > The Scheme compilation felt much slower, and for C++ ccache takes away
> > a lot of the pain of recompiles. It also appears to be
> > single-threaded? I admit not having timed it in detail.
>
> OK, I have very good news regarding compilation speed.
> Tests are done with
>
> rm -rf out/share/lilypond/current/guile/ && time out/bin/lilypond
> <...snip...>


> For one thing, Guile's optimization make about zero difference for the
> speed of the resulting LilyPond executable. For another, disabling
> optimizations in Guile 2 already results in a good speedup (1min
> to 20s), and while Guile 3 is even slower than Guile 2 at the default
> optimization level (1m30), with optimizations disabled it becomes
> near instant (3.5s).
>
> Guile 3 being far better at compilation speed with zero optimizations
> apparently comes from what is described in
>
> http://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile
>
> On the other hand, it does look like Guile 3 is a little slower
> than Guile 2 on execution time (5%).
>
> What do you think?
>
> Jean
>