[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blockers for Guile 2.2

From: Jean Abou Samra
Subject: Re: Blockers for Guile 2.2
Date: Wed, 9 Mar 2022 01:01:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

Le 26/02/2022 à 15:10, Jonas Hahnfeld a écrit :
Am Samstag, dem 26.02.2022 um 14:47 +0100 schrieb Jean Abou Samra:
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

(I have GUILE_AUTO_COMPILE=1 in my environment.)

* master and Guile 2

real    0m58,877s
user    0m58,773s
sys    0m0,124s

Execution time on

real    0m18,870s
user    0m18,727s
sys    0m0,470s

* Guile 2, with attached patch disabling all optimizations:
He, I always thought auto-compilation didn't optimize! 😕 now don't
tell me Guile also applies optimizations while just reading and
supposedly interpreting code...

real    0m16,791s
user    0m16,700s
sys    0m0,056s

Execution time on

real    0m18,702s
user    0m18,517s
sys    0m0,509s
[ skipping over the part regarding Guile 3, since I don't think it's
relevant here ]

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), [...].


What do you think?
Yes, it looks like we should do this! On the patch, I think it would be
better to apply the strategy from module/scripts/compile.scm and just
get all available-optimizations from the concatenation of tree-il-
default-optimization-options and cps-default-optimization-options
instead of hard-coding the list.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]