| In my last message, I showed that the pgcc compiler gives csound
substantial performance increases, as compared to standard GNU cc. Now
I'm looking at realtime benchmarks.
Recently I got help from the list on piping realtime events from another
application to csound via the -L flag. I've modified my code a bit for
benchmarking purposes, and done some tests.
There's no standard way to do realtime csound benchmarks, so these
are...
experimental realtime benchmarks
--------------------------------
All measurements were taken with a lightly-loaded X-windows session
active. It's a P133 system with 48 MB SDRAM and an EIDE hard drive.
Linux kernel version is 3.42. "top" shows the cpu is about 97% idle
before Csound starts.
Just in case Jim Stevenson isn't thoroughly sick of listening to
incomprehensible ASCII tables, here's my table format:
The first column gives the buffer size for the csound -b flag. The
second and third columns give scores for oscil and oscili,
respectively. Each of these two columns has one to three scores in
it. The first score represents the maximum number of voices obtainable
without getting sound breakups. The second score, if present,
represents the same thing, only this time tested while flinging the
mouse pointer quickly around the screen. The third score, if present,
gives the number of oscils that can be active before we start to hear
glitches at the start of each note. The fourth and fifth columns are
the same as the second and third, only testing the pgcc-compiled
version rather than the gcc-compiled version.
GCC PGCC
Buffer OSCIL OSCILI OSCIL OSCILI
------ ------ ------ ----- ------
64 32 0 0 25 0 0 37 0 0 27 0 0
128 37 0 0 27 0 0 39 0 2 28 0 2
256 32 0 32 27 0 27 39 0 38 28 0 28
512 37 33 36 28 26 28 40 31 40 28 18 28
1024 37 > > 27 > > 40 33 > 30 22 >
2048 39 > > 29 > > 43 35 > 29 22 >
4096 41 > > 29 > > 44 36 > 32 23 >
8192 42 > > 30 > > 44 38 > 32 24 >
16384 36 > > 31 > > 44 39 > 32 24 >
32768 37 > > 27 > > 39 39 > 29 22 >
65536 18 ? ? ? ? ? 19 ? ? 13 ? ?
When using realtime control, 512 is about the largest buffer size I
can use and still feel like notes play pretty much when I send
them. At higher settings, the delay is just too big for good-feeling
realtime control. At lower settings, there's too much gunk at the
beginning of each note.
In general, pgcc
improvement wasn't all that much compared to what I got with
non-realtime benchmarks ... Improvement ranged from none at all to 21.8%
better (for oscil at b = 256), and was usually more in the range of 5%.
The _increased_ mouse-induced glitching for Oscili is strange and
troubling. That was so unexpected that I checked the results a bunch of
times and always got within 1 point of the same scores... weird. I have
no explanation.
I should probably pick a more complex orc to use for testing; it's
pretty rare to just use one oscillator without even an envelope. :)
Attached is the file oscilRT.c which I used for the realtime
benchmarks. It does some unix-specific things; DOS or Mac people will
have to come up with their own realtime benchmark.
regards,
PW
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com |