[PD] puredata evolution

[Niklas Klügel]

Charles Henry wrote:
> I think it depends on the application.... for the most part, we can't
> get a generic speedup from using multiple cores (forgive me if wrong)
> that would apply to every single pd program..... but some types of
> computations such as large ffts can be performed faster when
> distributed to different cores, in which case, the code for the fft
> has to be parallelized a priori.  Plus, the memory is tricky.  You can
> have a memory access bottleneck, when using a shared memory resource
> between multiple processors.
> It's definitely a problem that is worth solving, but I'm not
> suggesting to do anything about it soon.  It sounds like something
> that would require a complete top-down re-design to be successful.
> yikes
>
> Chuck
>
>   
I once wrote such a toolset that does automatically scale up
with multiple threads throughout the whole network. it worked
by detecting cycles in the graph and splits of the signals while
segmenting the graph in autonomous sequential parts and essentially
adding some smart and lightweight locks everyhwere the signals
split or merged. it even reassigned threats on the lock-level to
"balance" the workload in the graph and preventing deadlocks.
the code is/was around 2.5k lines of c++ code and a bloody mess :)
so, i don't know much about the internals of pd but it'd be probably
possible.

so long...
Niklas

> On 5/29/07, Hans-Christoph Steiner <hans at eds.org> wrote:
>   
>> That is a tough problem.  On a basic level, Pd is ready right now for
>> two processors since it uses two separate processes: pd and pd-gui.
>> But the pd process does the heavy lifting, so it's a bit uneven.
>>
>> As for taking advantage of multiple cores, that is a lot more
>> complicated.  Max/MSP does have some support for threading
>> ("Overdrive" mode), but it seems to me that it is a hack.  It does
>> work, but it often leads to programs that are very hard to debug
>> since it is difficult to handle the non-determinancy of the situation.
>>
>> .hc
>>
>> On May 29, 2007, at 1:32 PM, 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
>>>
>>>
>>>
>>> _______________________________________________
>>> PD-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>>> listinfo/pd-list
>>>       
>>
>> ------------------------------------------------------------------------
>> ----
>>
>> If you are not part of the solution, you are part of the problem.
>>
>>
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>>     
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>