[chuck-users] benchmarking UGens

Kassen signal.automatique at gmail.com
Wed Mar 11 18:09:56 EDT 2009


Atte;

OR: it wasn't connected to dac :-)
>

Right, yes, that would explain it :¬)

>
> I'm not sure it was on purpose, but agree it's confusing at least by
> looking at the filename (I suspect you didn't look at the chuck code). With
> it connected it looks different:
>

Ah, yes. (pasting your notes from your other mail here)

> This means that the non-playing trick "s.samples() => s.pos" won't do
anything for the cpu (which I thought). It must be disconnected from dac to
be easy on the cpu...

That's right; that trick saves the ears, not the cpu. It's still a good
trick as it saves a lot of noise in setups where we use a lot of samples.

A different story: Do you have any ideas about how to test stuff like
> multiplication vs division?


What I came up seems very close to your solution

These results lead me to believe that the usual rave about division being
> expensive it totally irrelevant as soon as you connect even a single UGen in
> your chuck code :-)
>

The difference seems quite small indeed; intersting. I wonder how conditions
compare against those; I always thought those were relatively expensive.

PS; As a side note; GMail users can enable a google labs extension that will
>> allow them to view selected emails in fixed-width font. This makes looking
>> at tables like this a lot more convenient.
>>
>
> I'm using thunderbird...
>

My lifestyle forces me to use a web-based solution. I'd like to say that's
because of traveling so much but in reality it has to do with tinkering with
computers and OS's and occasionally having lost a install and all the mail
archives that were in it :¬)

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


More information about the chuck-users mailing list