Re: Sibelius Software UK office shuts down

[Han-Wen Nienhuys]

On Mon, Aug 6, 2012 at 2:57 PM, David Kastrup <address@hidden> wrote:
> Tim Roberts <address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen