[PD] How to reduce CPU use on unused subpatches-abstracts?

Charles Z Henry czhenry at gmail.com
Wed Aug 7 22:48:17 CEST 2013


On Wed, Aug 7, 2013 at 2:57 AM, Roman Haefeli <reduzent at gmail.com> wrote:

> On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
> > On 08/07/13 03:15, Miller Puckette wrote:
> > > Hmmm...  I was umnder the impression that, except for the overhead of
> block~
> > > and switch~ objects, there would be no difference in DSP execution time
> > > between a patch having lots of subpatches and one with the same amount
> of
> > > computation all thrown in one window.  I haven't made any measurements
> but
> > > theoreticall at least there shouldn't be any difference.
> >
> > i once did make measurements, and they showed that your assumption is
> > correct.
> >
> > or at least, it showed that it *was* correct at that time. this was on a
> > P2-400MHz in 1998 or so, where a 16 channel spatialization patch would
> > eat about 95% of the CPU - regardless of whether you used a single huge
> > patch or organized the code into subpatches/abstractions.
> >
> > eventually i went for using abstractions, and let the PC run at 95% for
> > the 2 weeks show.
>
> I once made some informal tests to measure the overhead of [switch~]. It
> turned out it is quite big and if you're running hundreds or thousands
> instances of [switch~] you probably gain nothing by turning DSP off in
> subpatches. I don't know what the sweet spot is it seems using [switch~]
> is only worth for subpatches with a minimum amount of (DSP) complexity.
>
> Roman
>

I don't know why this is so...
When you add a [switch~] object, it adds a prologue and epilogue around the
perform routines from each object in the subpatch.  The runtime behavior is
just like [block~], except when the patch is switched off, the switch
prologue returns a pointer to the epilogue, instead of the next item in the
dsp chain (don't quote me--I may need to read some code to find exact
behavior, but that's the gist of it).

To me, this is pretty minimal and reasonable.  Maybe there's an unintended
consequence like cache misses when skipping over part of the dsp chain.

 Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130807/6d3310c0/attachment-0001.htm>


More information about the Pd-list mailing list