[PD] Re: reduce CPU usage

chris clepper cclepper at artic.edu
Sun Jun 22 23:10:03 CEST 2003

>how can I reduce CPU usage generally?
>I made a patch that uses almost 90% CPU and everything gets really 
>slow. (graphically)
>It uses 82% CPU also if its "stands still" and does nothing.
>I m working on a Apple G4 1 Ghz, 1GB RAM etc.

the basic problem with your patch is that everything is on all the 
time.  even when you aren't using freeverb~ it's still processing 
audio, same for everything else in the patch.  that's why loading one 
or two sound files doesn't change the CPU load at all.  i don't 
actually know if pd has the equivalent of MSP mute~ object which 
turns processing on and off selectively (there's no mute~ in pd 
0.36).  that would make a world of difference in a large patch like 

freeverb~ is definitely the most CPU consuming part of your patch so 
consider using less of them.  perhaps use a send~ or throw~ with a *~ 
to send each signal chain off to one freeverb~ like a send on a mixer 
rather than use a separate one for each chain.  maybe a mixer patch 
would be a better way to control this patch in general.  you might 
also want to come with a way to break the patch into smaller patcher 
and only load parts as you need them.  this would cut down on cpu 
load when you are only using one or two sound files.

>I would be glad if somebody would help me with my patch so it gets "faster".

another big problem for you is that pd and none of it's externals are 
written for PowerPC.  a lot of the dsp  functions have just about the 
worst PPC code scheduling possible - the dis-assembly shows a 
horrifying number of stalls.  but to be fair most if not all of the 
external writers even have access to PPC boxes (although i can't 
imagine that some of the code runs well on any platform).  just 
looking at the 10 most CPU intensive functions in your patch i think 
the CPU load could easily be cut in half by re-writing the code to be 
more efficient.

>download it at . www.gezetera.ch/noise/supercpu.pd

it's a very cool patch, and i have to say it's one of the better 
looking ones i've seen.  it only took me a few minutes to figure out 
what was going on, which is great for something that complex.

one suggestion i have is that if you really want to do very complex 
large scale patches on PPC/OSX your best bet is probably 
SuperCollider as it's extensively optimized and would be able to run 
a patch like this easily.  of course it requires knowing SC and the 
way you would implement a patch like this would be entirely different.

>thank you in advance.
>miyazaki s

More information about the Pd-list mailing list