# Re: Gen~ efficiency comparison

Ooooook. I just finished an analysis of the cpu usage in a patch I’m making, and I thought I’d share my results. I only analyzed the audio objects that are actually in the patch (and a few others because I was curious), so there are a lot more that I haven’t touched. I’ve included the patch I used for the analysis in case anybody else wants to use it to find the relative cpu usage of an object. (Sample rate = 44100, Signal vector size = 256, Computer specs = Macbook Pro – OS X 10.7.3 – 8 GB ram – 2.5 GHz Intel Core i7)

The way I did the analysis was to make 1000 instances of an object, feed them all a constant value of 1 in an object-appropriate way, and then record the cpu utilization in a histogram for 10 seconds, at 100 millisecond intervals. From there, I extrapolated the range of cpu usage, the percentage it spent the most time on, and the per-instance cpu usage. These are listed in the format:

objectName minCPU-maxCPU, mostFrequentCPU@ratioOfOccurance | CPUperInstance

You can get an idea of how evenly the cpu values were distributed (aka how frequently it changed) by looking at the ratio of occurance, i.e. a ratio of 100/100 means it stayed on most frequent cpu value the whole time, but if it’s 20/100, that means the longest cumulative time of any one particular value was 2 seconds; very distributed.

Anyway, enough explanation. Here you go!

—-MSP OBJECTS—-

buffer~ 0, 0@100/100 | 0.
sig~ 2-5, 3@77/100 | 0.003
+~ 3-5, 4@70/100 | 0.004
*~ 3-8, 4@46/100 | 0.004
%~ 4-9, 4@40/100 | 0.004
trunc~ 4-11, 5@60/100 | 0.005
>~ 5-9, 6@53/100 | 0.006
selector~ 5-12, 6@73/100 | 0.006
gen~ 5-15, 6@21/100 | 0.006
phasor~ 7-12, 7@62/100 | 0.007
index~ 8-13, 8@74/100 | 0.008
poke~ 11-17, 12@66/100 | 0.012
gate~ 16-27, 17@52/100 | 0.017
count~ 18-27, 19@86/100 | 0.019
pow~ 24-35, 25@72/100 | 0.025

—-GEN~ OBJECTS(gen~cost included)—-

nothing 5-15, 6@21/100 | 0.006
const 5-15, 7@21/100 | 0.007
* 4-14, 7@22/100 | 0.007
+ 5-14, 7@25/100 | 0.007
gate 5-15, 7@25/100 | 0.007
selector 6-15, 8@25/100 | 0.008
trunc 11-32, 12@27/100 | 0.012
peek 13-30, 14@29/100 | 0.014
poke 30-34, 31@49/100 | 0.031
pow 42-66, 44@39/100 | 0.044
exp2 50-68, 52@46/100 | 0.052
% 68-98, 70@41/100 | 0.070

—-GEN~ OBJECTS(gen~cost subtracted)—-

nothing 0-0, 0@100/100 | *0.
const 0-0, 0@100/100 | *0.
* 0-0, 0@100/100 | *0.
+ 0-0, 0@100/100 | *0.
gate 0-0, 0@100/100 | *0.
selector 0-0, 0@100/100 | *0.
trunc 6-17, 6@27/100 | 0.006
peek 8-15, 8@29/100 | 0.008
poke 25, 25@100/100 | 0.025
pow 37-51, 38@39/100 | 0.038
exp2 45-53,46@46/100 | 0.046
% 63-83, 64@41/100 | 0.064

* may just be 0 because I didn’t do the subtraction of gen~’s cost properly
—————-

Based on the above analysis, it would seem that the most cost-effective way to patch is to use one gen~ object, and if you can accomplish what you want to accomplish with just the *, +, gate, and selector objects (other unexplored simple arithmetic objects excluded), then go for it. And if you at all can, stay away from the pow, exp2, and % objects, as these are THE MOST EXPENSIVE objects analyzed. True, this may be because they are 64-bit, but man. As mentioned in previous posts, I was running into cpu problems in my patch, and that would explain why. I think I use two gen objects with one pow, one trunc, and one % object each, and that shoots my cpu right up to about 2 percent, which is not good for an abstraction you want to run multiple instances of.

I hope someone finds this information useful, and again, if anybody else wants to do some analysis of other objects with my patch and share, feel free.

###### Attachments:
1. CPUtest.zip
May 18, 2012 at 7:15am #229326