[chuck-users] benchmarking UGens
signal.automatique at gmail.com
Wed Mar 11 18:09:56 EDT 2009
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 :¬)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users