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