Hi,
I don't know much about virtual machines, compiler technology etc, but I see
saol as my chance to learn...
What I'm wondering is whether we can assemble a list of all the known
performance bottlenecks in saolc. Here's a start:
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 )
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. )
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(?). )
4. Non optimized Ugen implementations. As ES has previously stated, the
ugens have been coded for clarity not efficiency.
5. Minimal program optimisation. (Various optimisations could be performed
on the parse tree before it is compiled into the runnable format.)
From my ignorant standpoint I'm thinking that the most efficient form to
compile a saolvm instrument would be a list of interleaved operation / data
pointers:
typedef void (*op)( void ***pc );
void * program[PROGRAM_LENGTH];
..
void **pc = program;
void **end = &program[PROGRAM_LEGTH-1]
while( pc != end )
((op)pc)( &pc );
program would contain pointers to operation functions, each followed by a
pointers to their parameters. The operation functions would manipulate pc
(program counter) such that apon their return pc is pointing at the next
function pointer to execute.
Is this too simplistic?
Ross.
.................................
http://www.audiomulch.com/~rossb/
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:33 EDT