On 02/21/2014 06:41 AM, Simon Wise wrote:
On 21/02/14 20:41, Charles Goyard wrote:
Hi,
just to give some example of single vs multi-threaded, and some comparison points.
- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded programming, even on multi-core computers. BUT they handle a much reduced number of use cases.
- graphics chipsets are massively parallel. They handle huge amounts of
data. BUT they are hard to build, they also handle a much recuced number of use cases, CUDA and OpenCL being a generalization.
- vvvv (on windows) has its core single-threaded, and a lot of objects
are multi-threaded, just like pd. It suffers the same than pd: when you get interactive with the GUI, the framerate slows down dramatically.
- whitecat (a DMX software) has its GUI that runs on OpenGL, and it's
not that efficient.
In the case of PD, maybe just a good mix of libpd and a generalization of pd~ can improve things much.
[pd~] deals with the particular case of creating an extra dsp thread, it incurs overhead to do so and does not isolate the dsp from a busy patch. It is quite orthogonal to creating separate gui, video, audio or whatever threads.
What I guess you mean is very different .. an object to launch a distinct pd process within (and isolated from) the rest of a pd patch. But I am not sure how that would be any better or more human-readable than 2 pd instances with [netsend]s and a suitable script to launch them together.
Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now.
Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent.
-Jonathan
Simon
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list