[PD] puredata evolution

[Miller Puckette]

Just to offer my two cents...

The great majority of DSP objects are side-effect-free and thread-safe.
In the base Pd distribution, I believe the main ones which are not are 
delread~/write~ (etc), tabread~/write~ (etc), send~/receive~, throw~/catch~, 
expr~, and dac~.  If these objects were avoided (or threadsafe versions 
written), then DSP networks could be parallelized at will.

Unfortunately, I have no idea what other objects there are (in the
many externs and libraries available) that might
be thread-unsafe, and what's more, I don't think there's any reliable way
to determine that an object is threadsafe.  So a parallelized version of
Pd would, in practice, occasionally crash mysteriously.  Furthermore, as
new DSP objects get written new sources of crashes would appear, leaving us
in all liklihood in a situation where no version of Pd ever emerged that was
entirely free of thread-related crashes.  Not a real pretty sight.

Another possibility would be to make Pd open up several address spaces and
run portions of the patch in then.  This was how Max/FTS worked on the ISPW.
It wasn't pleasant to use, though; for instance, a table on one processor
could easily get out of sync with one of the same name on another.

So it's hard to figure out what to do that would really help...

cheers
Miller

On Thu, May 31, 2007 at 06:49:44PM -0500, Charles Henry wrote:
> > Because it's cheaper to implement.
> >
> > If well done, it's also an intermediate step towards automatic threading.
> > It's important to cut hard goals into easier goals, because it reduces
> > required investment and gives quicker returns.
> 
> I think that's a very good point.  It could also lead to some new
> insights into the problem as a whole, during testing.  Top-down design
> is usually difficult because of misc problems you will find later on.
> I am curious... what kind of changes do you think would have to be
> made to allow this function?
> 
> I can imagine this explicit threading as a new type of sub-patch,
> which could be invoked in the same manner as [pd new_subpatch].  You
> could let the original process handle all the memory allocation, and
> switch on the new thread once its dependencies are satisfied.
> 
> > Also, I wouldn't trust automatic threading to make use of the CPUs in the
> > best possible way all of the time, *especially* for real-time.
> >
> 
> I would have to say... there's just no replacement for actually
> measuring the performance and making adjustments.  but you'll always
> be limited by the rate you can make the modifications yourself.  So,
> some kind of algorithm could be used to optimize performance, say,
> genetic algorithm style, or heuristic search.  So that you would
> create a patch which is intended to be used in a parallel arch and
> then you just sit back and let the computer try to optimize it by
> actually computing a bunch of cycles and taking measurements.
> Given that it's just a far off idea (to me), it's too soon to really
> discuss optimization :)  but if the computer were to actually take
> measurements and choose the best, I would trust the computer to do it
> faster/better than I could
> 
> >   _ _ __ ___ _____ ________ _____________ _____________________ ...
> > | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada
> > _______________________________________________
> > 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