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
