Michael wrote:
>I am certain that much of the speed problem with saolc is the parser.
I think this is only true for a very broad definition of 'parser'.
In saolc, what I consider parsing (that is, examining the code and
using it to form an abstract syntax tree) is only done once, at
orchestra startup. This part of the decoding process is negligable
compared to the run-time part.
On the other hand, many of the speed problems could be blamed on
the *sort* of parsing that is done, and how the orchestra is
prepared for run-time. Since there is a full AST (rather that
a p-code or VM implementation like SAINT or sarun), it has to
be traversed and interpreted every a-cycle. This is
incredibly wasteful. I think the biggest single speed
improvement in saolc would come from block-based processing,
so the AST only would have to be traversed once per k-cycle,
and each instruction would be internally looped to get its
full block of a-cycle executions.
As well as fixing all the expressions and core opcodes to
handle this, you'd have to add more logic in the static
analyzer to detect when it is possible to do block processing
(both sfront and SAINT do this, I think), and more run-time
logic to switch back to sample-by-sample processing when
it's necessary.
Other styles of syntax representation (like sarun's 3-address
machine) would likely be faster to interpret that saolc's
AST, too.
Best,
-- 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 1750 |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:46 EDT