2009/3/10 Atte André Jensen
We all know that chuck is not the fastest audio software out there. But I guess like me you've all found ways to work around that. I often found myself wondering "how much can I save by disconnecting this UGen" or "exactly how expensive is another NRev".
For this purpose I started to do some benchmarking in the form of a bunch of .ck files and a bash script. My initial results are here:
http://atte.dk/chuck/results.txt
The first line is "chuck --loop", so the wm alone. "nb" is the number of files, "cpu" is the cpu usage as reported by htop on my laptop (2Ghz Intel dualcore), and "cpu normalized" is cpu-usage (simple multiplication) at nb=100.
Of course this doesn't make sense without seeing the .ck files, so I've put them here:
http://atte.dk/chuck/performance_tests.tgz
I'm quite aware of that this approach is very un-scientific, so any input on how to improve it is more than welcome. Esp. I'm wondering how 10 * PRCRev = 7% and 50 * PRCRev = 46% (should have been 35%).
I'm gonna continue my tests, but you're all welcome to supply files for testing. Maybe this should all end up on the wiki?
NB: This is in no way a critique of the developers. Sure I would love to see a faster chuck, but we still love it and use it.
Interesting stuff! Please keep us informed. One useful benchmark I used when I was testing my Ruby ChucK library was "how many of this UGen can I connect to the dac before the audio starts to stutter?" In other words, how many copies of a UGen can chuck handle in real-time? It's perhaps more precise to use timings of chuck --silent (add UGens until chuck --silent takes as long as the amount of virtual time that passes), but the idea is the same. It would let you set up an exchange rate for UGens, like "1 Pan2 = 3 Gain". I only tested with Gain and SinOsc, but I found the numbers were fairly consistent as long as nothing else was running. Also, recommended reading: http://www.zedshaw.com/essays/programmer_stats.html If you skip the first half, there's actual information down below. -- Tom Lieber http://AllTom.com/