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

[Ed Kelly]

Whoa!

I wonder - this was a libpd app I made, and it definitely made a difference putting all the DSP on one layer, but it was complex and I may have missed a trick here. It runs on an iPhone, and I wonder if there is a difference in how that works. resolving abstractions and subpatches with audio dropped the CPU load on an iPhone 4 from 132% to 71%.

Unless teh people writing the GUI fixed a big bad bug without telling me? I didn't seem like that at the time...if it wasn't the case I could have saved myself some pain.

Cheers,
Ed
 
Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad
http://www.ninjajamm.com/


Gemnotes-0.2: Live music notation for Pure Data, now with dynamics!
http://sharktracks.co.uk/ 


>________________________________
> From: Charles Z Henry <czhenry at gmail.com>
>To: Roman Haefeli <reduzent at gmail.com> 
>Cc: pd-list <pd-list at iem.at> 
>Sent: Wednesday, 7 August 2013, 21:48
>Subject: Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
> 
>
>
>
>
>
>
>
>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
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130808/d023b7d5/attachment.htm>