On Wed, 9 Sep 2009, Phil Stone wrote:
Thanks for clarifying that, Hans, and for pointing out the issue with threads, IOhannes. One shouldn't be profligate with [pd~]s, strewing them all about and expecting performance gains -- therefore, one [pd~] per voice instance in a [polypoly] patch is probably not a good idea until we have 64-core CPUs as a regular thing! :-). However, with judicious use, [pd~] seems like it will allow Pd to scale to future processor design, and that's a good thing.
For large numbers of CPUs, and even for not so large ones, [pd~] is not so useful, as it has to be put explicitly in places where one would rather not have to put it, and where it can be quite complicated to introduce it.
If [pd~] were more like [pd] it would be more transparent; it would be easier to switch between the two. However, the most useful load-balancing cutting lines are not necessarily those of subpatches and they're even less those of whole patches (thus you have to artificially create separate patches wherever you want to spread work on several CPUs). I would believe that the most useful solutions would look more like Blechmann's [detach] and [join], but I don't know all of the implications of it.
...There is also a naming problem. It's expected that a ~ sign contrast such as [exp~] vs [exp] means that both classes are as similar as possible except one works on signals and the other doesn't. Despite Pd having some quirks about this, [pd~] introduces a big mental clash, so that now, when one explains the general meaning of ~, on has to make an exception for [pd~]. (If [pd~] were more like [pd], this problem wouldn't be any different.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
