[chuck-users] benchmarking UGens
signal.automatique at gmail.com
Tue Mar 10 11:55:51 EDT 2009
I'll check the difference. But it seems to me that for this purpose ("which
> of A and B is more expensive") it doesn't matter since we're interested in
> the relative speed of code.
I think getting as close as possible to the actual cost of a single UGen
would be useful. We may have several ways of constructing a certain sound
out of a few UGens, in that case the relative cost of single UGens would be
quite relevant. I recognise that we may not be able to find the exact cost
in all cases as it may depend on the context, especially if/when we would
start optimising ChucK but it could still be interesting to get as close as
Even the question of whether or not such a difference really exists in a
appreciable form would be interesting; such info would help us make more
informed choices about the the structure of our programs.
Agreed, and I have lot's of other ideas + plan on testing things as they
> occur in my work.
Great! I'm looking forward to reading about this.
You're absolutely right. I actually started something automatic, but got
> stuck, and thought a "by-hand" start was better than nothing. I'll for sure
> see if I can make a 100% automatic test.
Oh, yes, clearly, this is already quite interesting.
Eric had a interesting note about different kernels; I wonder whether that
would make a difference beyond the relative cost of UGens compared to
eachother (as percentages) and the overhead cost any given OS has for
running a program at all. I could imagine different CPU's making a
difference, provided we have a good compiler and compile each on it's own
system. We could create a standard for testing this; for example saying the
cost of a single SinOsc is "1", always using the same buffer size and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users