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