The notable thing to me here is that, using the rough
estimate that main_apass() is "overhead" and the rest
of the functions are "synthesis", sfront is spending
more than 90% of the time doing synthesis, and has only
about 10% overhead. This is exactly reversed in saolc,
which generally spends about 10% synthesis time, 90%
overhead.
The single most expensive function in saolc is usually
the switch statement that chooses the particular node
in the expression-evaluation tree -- in many
orchestras, 20% of the total time is spent evaluating
this switch statement!
Best,
-- Eric
-----Original Message-----
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
To: saol-dev@media.mit.edu <saol-dev@media.mit.edu>
Date: Wednesday, November 03, 1999 1:24 PM
Subject: PC.saol ...
>
> 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