background image

The quest for lost CPU cycles

June 7, 2005

I’ve just been testing the efficiency of various ways of controlling gain in MSP. The results surprised me somewhat. For each of the solutions I made 400 copies of the objects and measured CPU usage as reported by the DSP Status window. I’ve used a very slow ramp time (5000 ms) in order to be able to view CPU usage during the ramp. All tests were carried out on a Mac TiBook 1GHz running OSX10.3.9.

Here’s the results:

  • ~: Steady-state: 19%. Ramping not possible.
  • ~ and line~: Steady-state: 34-36%. During ramp: 39-41%
  • gain~: Steady-state: 23%. During ramp: 29%
  • matrix~ 1 1 1.: Steady-state: 24-25%. During ramp: 42-43%
  • 20 copies of matrix~ 20 20 1.: Steady-state: 46-49. During ramp: 63-66%.
  • jmod.gain~: Ramp not implemented. Steady-state: 100%

There are two major surprises here as far as I’m concerned.

The first is how light on CPU gain~ is. If you need to ramp signals there’s no doubt that this is the cheapest way to do it CPU wise. The only way to improve on gain~ is by using only *~ but that means that changes in gain levels will have to be handled by control rate signal and the ramp curves will be much less even.

I’ve done a similar test earlier on discussed on the Jamoma-developer mailing list. Back then Tim Place meant that that gain~ ramp is only updated at
the vector rate not the full sample rate hence the CPU savings. I’ve tested that as well and it do not seem to be true. The gain_ramp_study.pat patch illustrates that gain levels are adjusted continuously during ramps. (Click 128 and look at the content of capture~ when audio has been turned of.)

The other surprise is that matrix~ is so CPU-hungry. Some years ago while working on Norway Remixed I had a mail exchange with jhno of C’74 concluding that matrix~ was clearly the most efficient way of controlling gains. It might be that this was in the case of multiple inputs being routed to multiple outputs. This was back in OS9 days so it might be that the swich to OSX altivec optimized in the meantime. Still it’s surprising. matrix~ 1 1 1. shouldn’t be doing anything more than gain~ rather less as there’s no GUI involved.

When 20 x matrix~ 20 20 1. is more heavy than 400 x matrix~ 1 1 1. that must imply that in a multi-input multi-output matrix~ all routings in all directions are encountered for when processing audio even if 95% of all possible routes are muted in this particular case.

The test of jmod.gain~ was done out of curiousity. It’s no surprise that this becomes the heaviest solution. jmod.gain~ is really a horse of a different color routing soudn in two directions for wet/dry processing and mixing the returned signal.

You can download the test patches I used here.

On a side note this got me to think that maybe I should revitalize and open up the maxnerd wiki that I started preparing a long while ago. I’m not sure that anyone but me would bother about this kind of information though.