[PD] libpd separating gui from core

[Jonathan Wilkes]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list