>What I'm wondering is whether we can assemble a list of all the known
>performance bottlenecks in saolc. Here's a start:
"All known" bottlenecks would be a very long list. But I can make
some comments on yours and add a few more.
>1. Program is interpreted directly from the parse tree. ( An efficient
>compiled instrument definition (virtual program) should be created from
the
>parse tree for each instrument )
Yes, there's a huge amount of overhead in interpreting the parse
tree in saolc. Creating a virtual machine to do this efficiently
would help a lot, I think Giorgio has done some work on this, but
maybe it's currently proprietary. Also, it might be easier to apply
static optimization to VM code than to a parse tree in many cases.
>2. Each ugen currently allocates its own state memory. ( A compiled
>instrument definition should contain information such that when a new
>instrument instance (note) is allocated, one large block of memory for ugen
>state info is allocated, and offsets into this block for each ugen are
>precalculated as part of compiling instrument. )
Yes. This is a small amount of overhead for non-real-time, but
becomes significant in maintaining constant processing speed
for real-time performance.
>3. Opcodes are currently implemented as singe function with (i/k/a) rate
>switching inside opcodes where necessary. ( There should be separate
>functions for each rate primitive for rate dependent opcodes. A compiled
>instrument would have a separate subprogram for each rate(?). )
I'm not sure that this is necessarily much faster.
>4. Non optimized Ugen implementations. As ES has previously stated, the
>ugens have been coded for clarity not efficiency.
Yes, of course, and some very obvious improvements are possible (use
of closed-form expression for buzz(), for example).
A major one you didn't mention is the possibility of block-processing
the SAOL code much of the time. Since the semantics of SAOL are sample-
by-sample, you can't do this every time, but many instruments obviously
give the same answer whether you do the processing in blocks or in
samples:
instr foo() {
asig a;
table t(...);
a = 120;
output(oscil(t,a));
}
If you were to write block-processing versions of the ugens and implement
a feedback detector to figure out when you could use them, I bet many
useful things would run in real-time in saolc. This combined with (1)
could easily give you a ten-fold speedup, I think.
-- Eric
+-----------------+
| Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7|
|eds@media.mit.edu| < http://sound.media.mit.edu/~eds >
| 617 253 0112 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb|
+-----------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:33 EDT