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 <czhe...@gmail.com>
>To: Roman Haefeli <reduz...@gmail.com>
>Cc: pd-list <pd-list@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 <reduz...@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@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
