| Lately, I've been looking at interpreters suitable for use as
| extension languages in a control application. I need something that
| can do computation reasonably fast, say no worse than 1/10 of the
| speed of compiled C code. Interpreters have been written in that speed
| range quite often in the past. But when I try a few of the interpreters
| available on the Mac, performance is terrible.
suppose a computation takes x amount of time. to obtain 1/10 the
performance of compiled C code, which we can presume also takes x amount of
time, an interpreter has 9x amount of time to parse the input, and decide
what to do.
assuming no semi-compiled source, suppose you add floating point numbers
like in your example. you need to parse the input tokens (including a
floating-point literal), and look up a variable by name, before you can
perform the addition, then store the value back into the variable.
you assert that this can be done in 9 times the time it takes to add
floating point numbers, indeed that it has been done, even "quite often".
one contributor pointed out that this could be because "compiled C code"
had rotten performance. I would expect the difference between unoptimized
code and optimized code to be no more than one order of magnitude, and the
difference between unoptimized code and interpreted code to at _least_ be
another order of magnitude, so maybe there is truth to this, but I would
still like to see this assertion backed up by some real evidence.
the only way to vastly increase the execution time of interpreted code is
to semi-compile the code, and this was, indeed, the way most of those early
interpreters did their job. for instance, most BASIC interpreters did that
semi-compilation in the read phase, not the execution phase. maybe the
abysmal performance you see today comes from the fact that such semi-
compilation is not performed.
under GNU Emacs, the performance difference between byte-compiled lisp and
uncompiled lisp is very noticeable. the byte-compiled lisp is still
interpreted, but parsing and some optimization are done prior to execution.
if you need performance, may I suggest that you stop your search for an
ultra-fast interpreter, and instead spend some time on pre-compiling code
into something that _is_ 1/10 as fast as compiled C? this may not be a
simple task, though.
best regards,
</erik>
-- Erik Naggum <erik@naggum.no> <SGML@ifi.uio.no> | memento, terrigena. ISO 8879 SGML, ISO 10744 HyTime, ISO 10646 UCS | memento, vita brevis.for information on SGML and HyTime, try ftp.ifi.uio.no:/pub/SGML first.