Re: Sibelius Software UK office shuts down

[George_]

address@hidden wrote:
> 
> On 5 août 2012, at 12:37, Joseph Rushton Wakeling
> <address@hidden> wrote:
> 
>> On 02/08/12 17:51, Graham Percival wrote:
>>> In short: if there is a concerted effort to create a "quick
>>> render" output, I would be absolutely shocked if it wasn't at
>>> least 10 times faster than the current output.
>> 
>> (1) How paralellized is the current code -- and if not much or at all,
>> what do you think the scope is for doing so?  E.g. once basic pagination
>> is in place, could all other elements be engraved in separate per-page
>> threads?  Likewise, any parts of a score separated by an explicit page
>> break could be engraved by separate threads.
>> 
> 
> LilyPond currently only works on a single thread and the code base is
> definitely not optimized for parallel processing.  GCC may do this
> automatically when compiling LilyPond (I'm not sure how GCC works).  There
> are many places where parallel processing could be implemented in LilyPond
> - outputting broken lines and pages, as you suggest above, is one of them.
> 
>> (2) Are there any statistics on compile time vs. input file size?  It
>> doesn't necessarily help Lilypond to be blazingly fast on a 2-page,
>> 4-part choral score if it's horrendously slow in a 100-page
>> full-orchestra operatic score.  I recall that Valentin's opera was a
>> nightmare to render both in terms of time and of memory used along the
>> way.
> 
> In 2.15 we did some profiling on this a while back and sped this up
> considerably (there was a bottleneck in the code) but we haven't done any
> speed-up here since then.  I think LilyPond line breaking is O(n log n),
> although someone more into CS than I would have to confirm this.
> 
>> 
>> (3) The real speed issue is not so much from-scratch compile times but
>> recompile times -- how long _should_ it take to re-render the score if
>> e.g. I add a single staccato dot to one note?
> 
> One idea for LilyPond that has been kicked around for a while is that of
> .aux files.  LaTeX uses these and they help speed up compilation on second
> passes (they also make it more accurate).  The problem is that LilyPond
> currently has no API - it would take a few months of a few developers time
> to nail down a core API so that .aux files could be used predictably and
> without the creation of too many exceptions.  This is a high priority of
> mine but it is a bit too big for me these days and I've got my hands full
> w/ skyline work :-(
> 
> Cheers,
> MS
> 
>> 
>> Sibelius' publicity always used to make much of the fact that if Wagner
>> had wanted to add a new bar at the start of the entire Ring Cycle, using
>> Sibelius it would have taken no more than 1 second.  That kind of
>> speed-of-tweaking may be worth more than speed of first compile --
>> ideally, you'd be able to type stuff into the editor in e.g. Frescobaldi,
>> and see the score change in front of your eyes.
>> 
>> _______________________________________________
>> lilypond-user mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> 
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> 

Just here to post my thoughts:

Are there any potential changes to syntax that could speed up rendering, or
is the syntax arbitrarily decided and separate to the grunt work?

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? The number of clean-up threads would need to be
determined either dynamically during compile or statically before each
release comes out depending on projected workloads of each thread with
respect to theorised usage scenarios. I reckon, bearing in mind my complete
lack of knowledge about the Lilypond back end and programming in general,
that even though there'd be a ton of overhead, it'd be worth it - hardly
anybody runs single-thread systems nowadays. 

Bearing in mind, that any threading, in my opinion, should be aimed at
providing speed increases to large renders - >20-30s, at least; on shorter
renders any speed increases would be hard to notice, whereas in large
renders even increases of 5-10% would be huge over the whole process of
putting a score into Lilypond. And even having two threads would give much
greater boosts than that.
-- 
View this message in context: 
http://old.nabble.com/Sibelius-Software-UK-office-shuts-down-tp34245636p34260307.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.