bug-lilypond
[Top][All Lists]
Advanced

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

Aw: Re: New suggestion to make Lily pond speed up on multiple CPU cores


From: Arno Waschk
Subject: Aw: Re: New suggestion to make Lily pond speed up on multiple CPU cores
Date: Sun, 17 Jul 2022 18:24:16 +0200

   Well the hairpin thing mm ight be a bug for itself, as it happens with
   (for other reasons whatsoever) wanted pagebrakes as well.
   The difference I meant was that a pagebreak could in theory split a
   score in separated smaller scores to be compiled in parallel, and that
   could be done in very early stage of score processing, as opposed (I
   think) to linebreaks.
   Still the idea was mainly to have such parallelizing rather for a draft
   or development mode (where you can live with an odd hairpin), and still
   having the slow mode as currently for the final run where you don't
   want to have compromises in quality anywhere.
   Cheers, Arno
   --
   Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
   gesendet.

   Am 17.07.22, 16:04 schrieb Jean Abou Samra <jean@abou-samra.fr>:

     Le 15/07/2022 à 19:10, Arno Waschk a écrit :
     > Hi Jean,
     >
     > thanks for your reply!
     > I was aware of what you demonstrate and elaborate on line
     breaking,
     > but i tried to stick for pagebreaks in my statement for those very
     > reasons.
     Umm, if you replace \break with \pageBreak in my example, you will
     see that exactly the same problem exists with page breaks.
     \version "2.23.11"
     \paper {
       ragged-right = ##t
     }
     {
       c'1\<
       \pageBreak
       c'1\!
     }
     \pageBreak
     {
       c'1\<
       \pageBreak
       c'2 2\!
     }
     > I could have added that i mean fixed pagebreaks like when stated
     > explicitely by \pagebreak, or an equivalent a more or maybe even
     less
     > clever algo could add for speed up in some kind of draft mode,
     which
     > maybe useful even if suboptimal.
     It's not hard in each case to find some suboptimal value;
     you'd need to ensure, however, that an error does not ensue.
     I haven't tried it to see if it was hard.
     >
     > Probably you have a valid point about POSIX threads. Given that it
     > could not be solved by an equivalent of "make -j 8" and glueing
     things
     > together (which could be a quite quick and not too dirty solution
     > btw), we had at least something for non-windows users. :-)
     >
     > Hopefully someone with more insight could comment on that?
     >
     > Last not least, as anything happended around the gsoc idea, is
     there
     > any code for it?
     I don't think anyone took it.
     _______________________________________________
     bug-lilypond mailing list
     bug-lilypond@gnu.org
     [1]https://lists.gnu.org/mailman/listinfo/bug-lilypond

References

   1. https://lists.gnu.org/mailman/listinfo/bug-lilypond


reply via email to

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