unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Guile optimizations slowing down the program?
@ 2022-03-08 23:31 Jean Abou Samra
  2022-03-09  7:28 ` Maxime Devos
  0 siblings, 1 reply; 5+ messages in thread
From: Jean Abou Samra @ 2022-03-08 23:31 UTC (permalink / raw)
  To: guile-user, guile-devel

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guile optimizations slowing down the program?
  2022-03-08 23:31 Guile optimizations slowing down the program? Jean Abou Samra
@ 2022-03-09  7:28 ` Maxime Devos
  2022-03-09  7:53   ` Dr. Arne Babenhauserheide
  0 siblings, 1 reply; 5+ messages in thread
From: Maxime Devos @ 2022-03-09  7:28 UTC (permalink / raw)
  To: Jean Abou Samra, guile-user, guile-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guile optimizations slowing down the program?
  2022-03-09  7:28 ` Maxime Devos
@ 2022-03-09  7:53   ` Dr. Arne Babenhauserheide
  2022-03-09 10:01     ` Jean Abou Samra
  0 siblings, 1 reply; 5+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-03-09  7:53 UTC (permalink / raw)
  To: Maxime Devos; +Cc: Jean Abou Samra, guile-user, guile-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guile optimizations slowing down the program?
  2022-03-09  7:53   ` Dr. Arne Babenhauserheide
@ 2022-03-09 10:01     ` Jean Abou Samra
  2022-03-09 10:25       ` Dr. Arne Babenhauserheide
  0 siblings, 1 reply; 5+ messages in thread
From: Jean Abou Samra @ 2022-03-09 10:01 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide
  Cc: guile-user@gnu.org, Maxime Devos, guile-devel@gnu.org



> 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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guile optimizations slowing down the program?
  2022-03-09 10:01     ` Jean Abou Samra
@ 2022-03-09 10:25       ` Dr. Arne Babenhauserheide
  0 siblings, 0 replies; 5+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-03-09 10:25 UTC (permalink / raw)
  To: Jean Abou Samra; +Cc: guile-user@gnu.org, guile-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-03-09 10:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-08 23:31 Guile optimizations slowing down the program? Jean Abou Samra
2022-03-09  7:28 ` Maxime Devos
2022-03-09  7:53   ` Dr. Arne Babenhauserheide
2022-03-09 10:01     ` Jean Abou Samra
2022-03-09 10:25       ` Dr. Arne Babenhauserheide

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).