[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

[Hans-Christoph Steiner]

On Jan 25, 2012, at 6:32 PM, Peter Brinkmann wrote:

> 
> 
> On Wed, Jan 25, 2012 at 5:38 PM, Charles Henry <czhenry at gmail.com> wrote:
> On Wed, Jan 25, 2012 at 11:46 AM, Peter Brinkmann
> <peter.brinkmann at googlemail.com> wrote:
> >
> > Hi Chuck,
> > Check out the early bits of this thread --- various use cases already came
> > up along the way:
> > http://lists.puredata.info/pipermail/pd-dev/2012-01/017992.html.  The short
> > version is that libpd is being used in such a wide range of settings that
> > you can come up with legitimate use cases for pretty much anything (single
> > Pd instance shared between several threads, multiple Pd instances in one
> > thread, and anything in between).  At the level of the audio library, it's
> > impossible to make good assumptions about threading.
> 
> Hi Peter
> 
> That's the part I really don't understand, and I don't really have a
> clear picture of how you want to be able to control/choose between
> those cases.
> 
> Neither do I.  That's sort of the point here ;)  When it comes to libpd, all sorts of common assumptions go right out the window; a libpd-based application may not be interactive, or real-time, and it may not even run on any familiar hardware (there have been reports of libpd running on an embedded system, for instance).  The upshot is that libpd should only be in the business of processing samples and exchanging messages with client code; all other decisions should be made at another level, where more specific information is available.
>  
> I can also see how there could be more capabilities tied to having
> multiple threads generally.    But specifically, I can't say.  I have
> no clue.
> 
> >> I remember a conversation with IOhannes in August about
> >> multi-threading audio via sub-canvas user interface object (propose
> >> thread~ akin to block~).  If all you're after is audio
> >> multi-threading--there's no need for multiple instances of Pd.
> >> Threads could be used to start a portion of the dsp chain, running
> >> asynchronously, and then join/synchronize with Pd when finished.
> >
> >
> > I don't think a patch is the place where decisions about threading should be
> > made.  Threading is an implementation detail that users shouldn't have to
> > worry about, and besides, whether you have anything to gain from threading
> > will depend on a number of factors that users won't necessarily be able to
> > control or even know about.
> 
> I have a different view.  Every sort of use for Pd is like writing a
> program--you should assume Pd users are writing programs with every
> sort of tool you give them--the flipside to having to control
> threading explicitly is that you get to control how finely grained the
> threading is.  Putting it on the patching level is just the user
> interface--and it can work out nicely for grouping.  Even if you have
> some automatic tools, you may still want to have explicit control
> through another available interface (e.g. for debugging).
> 
> I don't think users have anything to gain from fine-grained control of threads.  That seems like an optimization hint that may or may not be helpful, depending on a lot of factors that are not obvious and will differ from machine to machine.  In any case, I don't want to have to think about threads when patching any more than I want to think about, say, NEON optimizations.
>  
> 
> > I believe it's much simpler than that.  It should be enough to just do a
> > topological sort of the signal processing graph; that'll tell you which
> > objects are ready to run at any given time, and then you can parallelize the
> > invocation of their perform functions (or not, depending on how many
> > processors are available).  I don't think there's any need to explicitly
> > synchronize much; tools like OpenMP should be able to handle this
> > implicitly.
> > Cheers,
> >      Peter
> 
> For that--the dspchain (an array of int*) makes a very bad structure.
> So, you'll want to re-write a handful of functions and data structures
> around having multiple concurrent branches of computations.  I
> actually really like this problem :D  I can picture a linked list of
> dspchains to do this.  But... the description of the sort algorithm
> really will determine what the data structure ought to be.
> 
> Hmm, I think that's a pretty standard scheduling problem.  All the necessary information is already in Pd, and it's being used when dsp_chain is computed.  It's just a matter of representing it as a dependency tree rather than a list, and then traversing the tree in the correct order.
> 
> The real question is whether there's anything to gain from this at all, or whether the overhead from parallelization will destroy any gains.  I always remember the cautionary tale of a complex system that was carefully designed to work with an arbitrary number n of threads, until it was profiled and the designers found that it works best when n == 1.


What I see as the most difficult challenge of parallelizing Pd dsp processing is how to ensure it remains deterministic.  That seems like it would add a lot of overhead.  The pd~ model seems like a good compromise: it allows you to break up patches into sections that will run on separate execution units, while providing only basic attempts at guaranteeing deterministic execution.  So that means, for example, your audio can be on one CPU, your video on another, yet each logical chunk is all running together as one process.

.hc

----------------------------------------------------------------------------

“We must become the change we want to see. - Mahatma Gandhi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120127/21e17731/attachment.htm>