Subject: [linux-audio-dev] sfront 0.65 09/07/00
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Fri Sep 08 2000 - 05:28:37 EEST
Hi lad-folk,
New sfront (0.65) release time, from a LAD-perspective, the
interesting code changes revolved around how to generate C code that
gcc can compile in a reasonable amount of time. The core tricks were
pretty straightforward:
[1] Don't spread out in space (i.e. create many specialized functions)
for things that don't have to go very fast. C-code generation for
creating SAOL and SASL wavetables were rewritten to eliminate this bad
behavior, which cut compile time from minutes to a few seconds for
SAOL that exercised tables a lot, and oparray code was improved in
this way also.
[2] If you're using gcc, and you're creating C code for constant float
tables that you want compiled fast, turn the data into hexadecimal
strings:
char foo[5] = "\x00\x00\xa0\x41";
compiles quicker than
float foo[1] = { 0.39485};
once the arrays get big. Unfortunately, Sun's cc doesn't like this,
it doesn't seem to be able to handle embedded \x00's in the string
well (it terminates the string constant, since strings are NULL
terminated -- I think that's the failure mode, but I'm not sure).
Full sfront 0.65 saol-devs announcement appended ...
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
----Pick up sfront 0.65 09/07/00 at:
http://www.cs.berkeley.edu/~lazzaro/sa/
Change log message:
[1] C code generated for SAOL and SASL wavetables compiles much quicker and runs with improved cache behavior. C code created for the "sample" wavetable generator no longer includes an WAV or AIFF parser, and moderately-sized constant tables for all generators are computed by sfront and placed into the sa.c file as constant float arrays. On some machine/ compiler configurations, the sfront -hexdata flag offers additional compilation speedup, by encoding arrays as hexadecimal strings.
[2] C code generated for wide oparrays compiles much quicker and runs with improved cache behavior (thanks to Richard Dobson).
[3] Many sa.c memory leaks involving wavetables have been fixed, reducing the working memory space of table-intensive programs.
[4] Bugfixes involving the dur standard name (thanks to Tobiah), empty opcode return() statements (thanks to Ross Bencina), name space collisions (thanks to Aaron Finch), oparrays, and wavetables.
-----
Several test examples drove these optimizations:
[A] The perc example, which took sfront 0.64 a long time to compile, due to lengthy WAV file reading code. Sfront 0.65 produces code that compiles 15X faster on perc:
0.64 0.65
sfront 0.11s 0.09s run time
gcc 50s 3.3s run time
[B] A simple sdiff2mp4 example of a trumpet blast, created by Richard Dobson. Sfront64 behaved very poorly for this MP4 file, taking many many minutes to compile the sa.c file, which ran slowly. One major problem was this oparray call:
instr track(){
oparray oscil[ 1024 ];
}
which sfront created 1024 functions for! A second problem was the 228 SASL data wavegenerator tables, each of which sfront generated several hundreds of lines of code for. Sfront 0.65 generates sensible oparray and SASL table C code for these SAOL constructs, here's a performance measurment of the trumpet blast for 0.65:
--
% /usr/bin/time -p sfront65 -aout linux -playback \ -orc trump.saol -sco trump.sasl -latency 0.743039
sfront, a SAOL to C translator. Version 0.65 09/07/00. Run sfront with -license option for Copyright/License info.
real 0.71 user 0.58 sys 0.13
% /usr/bin/time -p gcc -O3 sa.c -lm -o sa real 3.84 user 3.73 sys 0.11
--
and the trumpet blast plays in real-time on my 450MHz PIII.
This archive was generated by hypermail 2b28 : Fri Sep 08 2000 - 06:21:25 EEST