[PD] future directions for threading in Pd (Was: Re: puredata evolution)

[Phil Stone]

Heh.  I composed an email this morning proposing a less fine-grained, 
manual approach to parallelism in Pd, perhaps at the subpatch level with 
switch~/block~-like control.

I trashed the email, because I figured it was too much to hope for, and 
I don't understand PD internals well enough to know it it's even feasible.

And now to hear it's being thought about in DD...this is so cool!  I 
really hope it can happen.  Please keep us posted on any developments.


Phil




Claude Heiland-Allen wrote:
> Phil Stone wrote:
>> This has been a fascinating thread about the direction of PD.
>>
>> I've been thinking about parallelism and PD as multi-core processors 
>> become common.  How hard would it be to make PD able to take 
>> advantage of parallel architecture?  I'm guessing that it is 
>> decidedly non-trivial, as lack of threading is already an issue in 
>> contention between the GUI and audio processing.
>>
>> Without some support for parallelism, PD could be going as fast as it 
>> will ever go -- the trend seems to be that CPU speeds will not be 
>> climbing much (at least not dramatically like they have until now), 
>> and increasing numbers of cores will be the path to greater speed and 
>> power.
>> Is there any hope in this direction?
>>
>>
>> Phil Stone
>
> I had a discussion with matju in #dataflow [1] last week about 
> possible directions for multithreading in Pd.  The general conclusions 
> we reached were roughly:
>
> 1. threading/parallelism is necessary, and will become more necessary
>
> 2. trying to automatically split the computational load between 
> multiple threads will be very difficult and the result sub-optimal
>
> 3. solution: a primitive in Pd for manually controlled threading
>
> 4. the existing threading externals are error prone, because you need 
> object delimiters at all boundaries of the non-specific region to be 
> threaded, otherwise horrible crashes can result
>
> 5. methods already exist in Pd for defining specific regions, namely 
> abstractions and subpatches
>
> 6. there are already objects that change the properties of those 
> specific regions, namely [block~] and [switch~]
>
> 7. a similar object could be created to make a specific region a 
> separate thread, which would change the behaviour of [inlet] [outlet] 
> etc to communicate between threads, much like [block~] changes the 
> behaviour of [inlet~] etc to communicate between different signal 
> vector block sizes.
>
> 8. arguments and messages to the [thread] object (or however it is 
> named) could adjust the thread priority, or other parameters.
>
>
> Claude
>
> [1] irc://irc.freenode.net/#dataflow
>