Re: State of LilyPond with Guile 2.2

[Jonas Hahnfeld]

Am Sonntag, dem 11.04.2021 um 16:04 +0200 schrieb Han-Wen Nienhuys:
> On Sun, Apr 11, 2021 at 3:42 PM Jonas Hahnfeld via Discussions on
> LilyPond development <lilypond-devel@gnu.org> wrote:
> > 
> > All numbers are from my laptop running Arch Linux (with pango
> > downgraded to 1:1.48.2-1 to keep out the memory hogging in 1.48.3)
> > and
> > measured with "/usr/bin/time -v". I use commit fce156f219 from
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/723 (see
> > User's
> > View) and the system-provided versions of Guile 1.8.8 and Guile
> > 2.2.6.
> > I don't test Guile 3.0 because it's not available as package, and
> > there
> > seem to be more changes needed to make it even work.
> > I configured the build with --enable-gs-api (because I'm interested
> > in
> > the time spent in LilyPond, not how fast the system can fork gs)
> > 
> 
> I assume this is also without extractpdfmark, which is also a CPU
> hog. 

Correct, all numbers are without extractpdfmark.

> > The first set of experiments is about things that developers care
> > about, namely 'make test' and 'make doc'. For all runs, I used the
> > options "-j4 CPU_COUNT=4".
> > 
> > 'make test' when compiled with Guile 1.8.8:
> >  * User time (seconds): 520.68
> >  * Elapsed (wall clock) time (h:mm:ss or m:ss): 3:59.54
> > 
> 
> IIRC, on my 4 CPU machine, the actual time running the regression .ly
> files is fairly low (about 1 minute). A lot of time is spent running
> the lilypond-book regression tests, which makes this difference all
> the more dramatic

True, but the current way of testing lilypond-book is kind of the
worst-case scenario for LilyPond because all files are compiled
separately. So 37 times a startup time of 2 seconds is already the
majority of the slowdown.

>  
> >  * Maximum resident set size (kbytes): 372560
> > 'make test' when compiled with Guile 2.2.6:
> >  * User time (seconds): 710.35
> >  * Elapsed (wall clock) time (h:mm:ss or m:ss): 5:43.04
> >  * Maximum resident set size (kbytes): 372344
> > 
> > -> 40% slower when using Guile 2.2.6 during development
> > 
> 
> 
> I didn't see you mention this explicitly: for apples to apples
> comparisons, you have to disable 'debug-gc-object-lifetimes feature.
> It causes a significant slowdown with Guile 1.8 for make test/make
> doc, so the comparison is probably worse.
> 
> This comes at the expense of increased memory usage (which reduces GC
> overhead), so you'd have to test with my GUILE patches for a
> completely honest comparison. I think the advantage of the decreased
> GC overhead is minor, though.

Right, I didn't think about this. However, I compiled without --enable-
checking so the actual difference is just garbage collection happening
between the files, which you think should be minor. Also "apples to
apples" comparison means without your patches, because that's what
users get.

> 
> > In my opinion, the numbers show that we *must have* compiled
> > bytecode
> > for user installations in order to reach acceptable performance
> > (memory
> > usage seems to be fine). And while compilation by invoking LilyPond
> > is
> > somewhat odd, it works and would be viable for the beginning.
> > 
> > For development, I'm less convinced. Sure, 'make test' and 'make
> > doc'
> > get faster but the compilation itself takes a considerable amount
> > of
> > time. Moreover it is my understanding the Guile is notoriously bad
> > at
> > determining which files to recompile, in particular when macros are
> > involved.
> > 
> > Personally, I would be ok with the moderate slowdown if that was
> > the
> > only thing preventing a hypothetic switch to Guile 2.2, and the
> > arising
> > 
> 
> 
> What does "switch to" mean precisely? Do you mean "remove support for
> guile 1.8", "make 2.2 the default (when given the choice) but keep
> supporting 1.8" ?

Eventually, I think the target should be to "remove support for Guile
1.8". In particular once we provide binaries with Guile 2.2, that will
be the one version we care about.

>  
> > question is really a matter of prioritizing: There are other items
> > that
> > need solutions before that switch could happen (in particular the
> > release process for binary builds and documentation). What do
> > others
> > think? Or would you say that proper bytecode compilation is
> > required
> > before moving to Guile 2.2? (with no clear estimate how feasible
> > that
> > is and how long it would take)
> > 
> 
> 
> How hard is it really to byte-compile the files during the build?

With "guild compile"? I don't know.

> Could we run lilypond during the compile and collect the .go files?

Running the mentioned GUILE_AUTO_COMPILE during a non-cross-build is
simple, but you'll need to remove the files yourself because Guile
might not pick up changes to macro definitions which will be very odd
to debug. You don't even need to collect them, that's only for
installation.

> Are they architecture independent (could we still cross-compile to
> windows?)

My understanding is that they depend on pointer size and endianess, so
you can take the files from x86_64-unknown-linux-gnu for Windows. But
we'll need to test.

Jonas

signature.asc
Description: This is a digitally signed message part