Running on a PIII 450 Mhz under Linux and using gcc
to compile the sa.c file produced by sfront 0.44:
% make timing
/usr/bin/time -p ./sa
real 64.34
user 64.07
sys 0.23
One caveat is that srate was the CD sample rate here
(44100Hz) mostly to avoid playback artifacts on my soundcard.
Note that since the composition itself takes 67seconds, this
is "real time", although in fact since most of the complex
notes are backloaded at the end of the piece, it won't really
play out at real time quite yet.
Where do the cycles go? Gprof'ing sa.c yields:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ns/call ns/call name
42.81 27.24 27.24 14604788 1865.14 1865.14 smallgong_buzz12
15.81 37.30 10.06 11086944 907.37 907.37 celeste_aexpon3
7.83 42.28 4.98 14604788 340.98 340.98 smallgong_oscil10
6.08 46.15 3.87 11086944 349.06 349.06 celeste_oscil7
5.00 49.33 3.18 2960364 1074.19 20494.10 main_apass
2.40 50.86 1.53 877272 1744.04 1744.04 medgong_buzz15
2.39 52.38 1.52 877272 1732.64 1732.64 medgong_buzz13
2.39 53.90 1.52 main
2.25 55.33 1.43 11086944 128.98 128.98 celeste_bandpass5
1.23 56.11 0.78 2960364 263.48 263.48 schroeder1_allpass
Looking at the top ten, the buzz() call in smallgong is the
main culprit -- buzz() in sfront right now is implemented in a very
straightforward way, doing sin() calls from the library and summing
them up. Buzz is actually a good case study of the type of optimization
I'm rewriting sfront to do well, here's the parameter list:
buzz(asig cps, ksig nharm, ksig lowharm, ksig rolloff)
Where cps is the frequency of the waveform, nharm and
lowharm sets the number of sin's to sum, and rolloff is the
weighting factor for each sin.
The fastest way to implement buzz depends on the characteristics
of the four parameters, namely:
-- are they constant's?
-- if not, are they ivar's or ksig's or asig's
-- are they integer's?
Depending on these questions, the best implementation could
be:
-- table lookup
-- an expression derived from a known series summation of the formula
for buzz, see page 273 of F. Richard Moore's book "Elements of
Computer Music". There are several ways to convert this equation
to a buzz() implementation via trig identities, each of which is
useful for different parameter characteristics.
Both of which are much faster than the way sfront currently
implements it.
The eventual goal for sfront is to generate, for each call
(synatically speaking) to buzz, the optimal code for it given what's
known at compile time. This strategy extends to most of the other
a-rate core opcodes as well.
--jl
P.S. The other top cycle-wasters for PC.saol have similar stories
behind them ...
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:43 EDT