Re: Why are intepreters so slow today

Erik Naggum (erik@naggum.no)
16 Apr 1994 17:42:37 +0200

[John Nagle]

| 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.