[PD] implications of pd~ for 'poly' objects
matju at artengine.ca
Mon Sep 21 22:16:05 CEST 2009
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
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
More information about the Pd-list