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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
