Hi, LilyPond has a fairly sized body of Scheme code. With Guile 2, the byte-compilation with default settings takes 1 minute, and 1min30 with Guile 3, so I've been experimenting with reducing optimizations to make it faster for development cycles. I've found that disabling optimizations reduces the byte-compilation time to 20s in Guile 2, and just 4s in Guile 3 (thanks to the baseline compiler). Naturally, I've tried to see how much that slowed down the resulting version of LilyPond. To my surprise, it looks like these unoptimized versions are actually faster. In Guile 2, I'm not sure if the difference is significant, but it definitely looks so in Guile 3. This is one benchmark, comparing optimization level 0 against level 2 (the latter is the default): Baseline New executable Delta _________________________________________________________________________________________ │ Min │ 4.060 │ 4.020 │ -0.99% │ │ Mean │ 4.138 │ 4.096 │ -1.03% │ │ │ │ │ (difference is -2.86 times standard error) │ │ Standard error │ 0.014 │ 0.015 │ │ └────────────────┴──────────┴────────────────┴────────────────────────────────────────────┘ Here's a different benchmark (on a much larger LilyPond file): Baseline New executable Delta ___________________________________________________________________________________________ │ Min │ 35.380 │ 34.600 │ -2.20% │ │ Mean │ 36.065 │ 34.913 │ -3.20% │ │ │ │ │ (difference is -9.10 times standard error) │ │ Standard error │ 0.173 │ 0.080 │ │ └────────────────┴──────────┴────────────────┴────────────────────────────────────────────┘ Same benchmarks, with optimization level 1: Baseline New executable Delta ___________________________________________________________________________________________ │ Min │ 4.040 │ 4.040 │ 0.00% │ │ Mean │ 4.256 │ 4.244 │ -0.28% │ │ │ │ │ (difference is -0.57 times standard error) │ │ Standard error │ 0.022 │ 0.020 │ │ └─────────────────────────────────────────────────────────────────────────────────────────| Baseline New executable Delta ___________________________________________________________________________________________ │ Min │ 35.500 │ 34.450 │ -2.96% │ │ Mean │ 36.069 │ 35.081 │ -2.74% │ │ │ │ │ (difference is -6.27 times standard error) │ │ Standard error │ 0.117 │ 0.198 │ │ └────────────────┴──────────┴────────────────┴────────────────────────────────────────────┘ In summary, the less Guile optimizes, the faster LilyPond runs. Is that something expected? Best, Jean
[-- Attachment #1: Type: text/plain, Size: 246 bytes --] Jean Abou Samra schreef op wo 09-03-2022 om 00:31 [+0100]: > In summary, the less Guile optimizes, the faster LilyPond runs. Is that > something expected? I don't think so, but I don't have a clue how this happens ... Greetings, Maxime [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --] Maxime Devos <maximedevos@telenet.be> writes: > Jean Abou Samra schreef op wo 09-03-2022 om 00:31 [+0100]: >> In summary, the less Guile optimizes, the faster LilyPond runs. Is that >> something expected? > > I don't think so, but I don't have a clue how this happens ... Do I understand it correctly that Lilypond has lots of snippets that are executed exactly once? In that case it could be expected that the overhead of optimization dominates — maybe even the overhead of increased code-size from inlining? Also the new baseline compiler is already pretty good: https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile Maybe this? > There is also a felicitous feedback effect in that because the > baseline compiler is much smaller than the CPS compiler, it takes less > time to macro-expand — https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1121 bytes --]
> Le 9 mars 2022 à 08:53, "Dr. Arne Babenhauserheide" <arne_bab@web.de> a écrit : > > > Maxime Devos <maximedevos@telenet.be> writes: >> Jean Abou Samra schreef op wo 09-03-2022 om 00:31 [+0100]: >>> In summary, the less Guile optimizes, the faster LilyPond runs. Is that >>> something expected? >> >> I don't think so, but I don't have a clue how this happens ... > > Do I understand it correctly that Lilypond has lots of snippets that are > executed exactly once? In that case it could be expected that the > overhead of optimization dominates — maybe even the overhead of > increased code-size from inlining? What is byte-compiled in these experiments is not the code from .ly files (which is always evaluated via primitive-eval and not compiled), but the code from LilyPond's .scm files. The compilation is done ahead of time, so its overhead can't be responsible for these results. > Also the new baseline compiler is already pretty good: > https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile > Maybe this? > >> There is also a felicitous feedback effect in that because the >> baseline compiler is much smaller than the CPS compiler, it takes less >> time to macro-expand — https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile As far as I understand, this is about the speed of compilation. For the reason explained above, it doesn't factor into the speed of LilyPond. Thanks for responding! Jean > > Best wishes, > Arne > -- > Unpolitisch sein > heißt politisch sein, > ohne es zu merken. > draketo.de
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --] Jean Abou Samra <jean@abou-samra.fr> writes: >>> There is also a felicitous feedback effect in that because the >>> baseline compiler is much smaller than the CPS compiler, it takes less >>> time to macro-expand — https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile > > As far as I understand, this is about the speed of compilation. For > the reason explained above, it doesn't factor into the speed of > LilyPond. The speed of compilation is only part of it. The blog post also shows that the optimizations gain factor 4 in speed for the compiled code, but if there are lots of macros to expand in the *.ly files, unoptimized code (which is smaller, because it is higher-level) might actually be faster. This as all highly speculative on my side, though … > Thanks for responding! In my opinion Lilypond is one of the most important Guile-Programs. Since I started running Guix as Distro, Lilypond is no longer *the* most important Guile program for me (since without Guix my system would simply not run), but Lilypond is still the one tool I really need. All the other Guile-using utilities I have are nice to have conveniences (or code I wrote myself). Lilypond is the only mission-critical tool for which I would not be able to find a replacement, because I require it to improve my songbook. There’s just nothing like it. Thank you very much for working on Lilypond! Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]