[PD] puredata evolution

[Tim Blechmann]

On Wed, 2007-05-30 at 12:13 +0200, Niklas Klügel 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. 

detaching ffts (i.e. canvases with larger blocksizes than 64) should be
rather trivial ... 

distributing a synchronous dsp graph to several threads is not trivial,
especially when it comes to a huge number of nodes. for small numbers of
nodes the approach of jackdmp, using a dynamic dataflow scheduling, is
probably usable, but when it comes to huge dsp graphs, the
synchronization overhead is probably to big, so the graph would have to
be split to parallel chunks which are then scheduled ...
and of course, an implementation has to be lockfree, if it should be
usable in low-latency environments ...

cheers, tim

--
tim at klingt.org    ICQ: 96771783
http://tim.klingt.org

Your mind will answer most questions if you learn to relax and wait
for the answer.
  William S. Burroughs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070530/f38d1361/attachment.pgp>