unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Jean Abou Samra <jean@abou-samra.fr>
To: guile-user@gnu.org, guile-devel@gnu.org
Subject: Guile optimizations slowing down the program?
Date: Wed, 9 Mar 2022 00:31:56 +0100	[thread overview]
Message-ID: <4f80c059-4e10-1c0b-33d4-e73c66da297c@abou-samra.fr> (raw)

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




             reply	other threads:[~2022-03-08 23:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 23:31 Jean Abou Samra [this message]
2022-03-09  7:28 ` Guile optimizations slowing down the program? 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f80c059-4e10-1c0b-33d4-e73c66da297c@abou-samra.fr \
    --to=jean@abou-samra.fr \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).