On Mon, Aug 6, 2012 at 2:57 PM, David Kastrup <d...@gnu.org> wrote: > Tim Roberts <t...@probo.com> writes: > >> George_ wrote: >>> WRT (1): Someone in this thread suggested using individual threads to render >>> a bar at a time. The end result would be messy, but what if one or two >>> threads were dedicated to running 'behind' the main threads to clean up and >>> knit together output? >> >> Multithreading works well when there are "natural" subdivisions of the >> work. It's really hard to come up with a "natural" subdivision for >> Lilypond. Bars are not particularly fundamental to Lilypond music. Bar >> lines are just another thing that get engraved. Plus, Lilypond does not >> require that all staves in a system have the same bar structure. >> Dividing into systems would be convenient, but you don't really know >> where the next system starts until you're done with the current one. > > Uh, no? AFAIK, LilyPond uses linear programming, and that requires > combing through a currently active set of optima and generating the next > set. That is at its heart a parallel operation.
The problem is that to get at the input data for linear programming, it has to run a lot of callbacks, many of which have side effects, eg. due to caching. If you do that multithreaded, you have to properly serialize all side-effects, which I think is intractable, since the data structures were never setup to be thread safe. Also, going MT will give you a max 8x speedup (assuming perfect parallelization on an 8 core machine). That is not going to bring down processing costs to interactive rates. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
