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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list