[PD] puredata evolution

[Chris McCormick]

On Wed, May 30, 2007 at 01:45:00PM +0200, Tim Blechmann wrote:
> On Wed, 2007-05-30 at 12:13 +0200, Niklas Klügel wrote:
> 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 ...

The logical extension of the current trend in processors (Core 2 duo,
Cell processor) seems to be greater and greater parallelism. Maybe this
is completely naïve, but once we reach the situation where we have more
cores/vector processors than we do nodes in our graph, can't we just
assign one node to each processor and wait for the slowest one to
finish? Given that currently the slowest one is much much faster than
it takes to compute our smallest blocksize. I don't think we are too
far off from having 4096 processors on one chip.

Speaking of that; sequential programming is going to start sucking really
badly when that happens. Concurrent languages like Erlang, Parallel
Haskell, and Puredata (if it adapts fast enough) are going to rule.

Best,

Chris.

-------------------
http://mccormick.cx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070530/08228243/attachment.pgp>