On Mon, Aug 6, 2012 at 9:56 PM, George_ <georgexu...@gmail.com> wrote:
> The reason this is important is because while IPC goes up incrementally and
> relatively slowly (IPC has done little more than double between 2005 [P4
> 660] and now [i7 3930X]) and clock speed is relatively stagnant (it's
> unlikely we'll ever get 8GHz stock x86 CPUs the way Intel predicted), core
> count is the only real way to dramatically improve performance - over a
> similar period, core count has gone up six-fold (in high-end parts), and
> it's set to continue. I agree, talking about a typesetting program running
> on a 192-core ARM server is a bit silly, but then, so is saying that an
> 8-fold increase in speed won't make the process instantaneous, then implying
> that for this reason we shouldn't look for ways to make it work.

I'm trying to explain that the constant factor (namely 8-fold) comes
at a tremendous cost. Writing multithreaded code without getting stuck
in race-conditions and deadlocks is extremely difficult and time
consuming, and lilypond already has a shortage of developers without
taking on parallelism.

In the context of the original remark (making lilypond more suited as
a rendering engine), multithreading is simply a stupid way to spend
programmer resources. If you're writing a GUI using Lily as a
renderer, have the GUI manage the data structures (and possibly, the
parallelism), so LilyPond can suffice to stay "simple" and
single-threaded,

-- 
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

Reply via email to