[chuck-users] benchmarking UGens

[Kassen]

Atte;

Another day, more testing!

They are indeed more expensive than their counterparts. Number of harmonics
> doesn't seem to matter, though (see link below).
>


Interesting; I expected them to be more expensive but I wasn't sure we could
get any number of harmonics for that price.


>  Another interesting thing to compare might be LiSa with multiple voices
>> v.s. as many copies of SndBuf.
>>
>
> Hmm. Could you supply a test file for this?
>


Let me think about this because doing this in a way that's as neutral as
possible doesn't seem so easy now that I considered it.


>
>
>  The list goes on; we might want to know the cost of member functions like
>> the .freq() parameter of filters, we may even want to know the cost of
>> certain operations.
>>
>
> But this (and other operations needs to be done at a rate. Would every samp
> make sense? Or should we pump more operations per samp, for instance with a
> inline repeat?
>

I'd say we need to do it at whatever rate gives us numbers in a 40-80% (or
so) CPU usage range because of the factors you pointed out previously; at
too little CPU usage other factors weigh too heavily, at too much the
measuring will likely become inaccurate. Maybe a inline repeat makes more
sense than looping at fractions of a samp; we'd have less conditions (per
second) but that would also make the code slightly more complicated and I'm
also in favour of simple code here for simple analysis. Sigh; not so easy,
this.



>
> Another thing: Some UGens could prove more expensive in use (Envelope and
> ADSR seems to fall into this category), which ones should I test, and how?
> For Envelope/ADSR I simply connected them to a SinOsc, and found that the
> cost of ADSR => SinOsc => dac is more than ADSR => dac + SinOsc => dac.
>

The one difference I know for sure is there is that in the case of chaining
them up there will be a second UGen pulling ticks through the chain; you
won't have just dac polling the envelope and the osc but you'll have dac
polling the osc, then the osc polling the envelope. Maybe that's more
expensive. It could also be that SinOsc calculates numbers in a more
complicated way when it's fed a signal to it's sync input? I suppose that to
get beyond this we're simply going to have to dig into the code to see what
exactly is going on there. There might be something going on that will be
interesting should we want to optimise UGen graphs for speed of calculation.


>
> I've wrapped it up a bit, with direct links to the test files for easier
> browsing:
>
> http://atte.dk/chuck/
>
>
Cool!

Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090312/7f2d12dd/attachment-0001.html>