Re: Why are intepreters so slow today

Lawrence G. Mayka (lgm@polaris.ih.att.com)
Sat, 16 Apr 1994 21:13:43 GMT

In article <nagleCoACH4.25p@netcom.com> nagle@netcom.com (John Nagle) writes:

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.

My basic test is to run something equivalent to

int i; double x = 0.0;
for (i = 0; i < 1000000; i++) x = x + 1.0;

The Smalltalk and Python versions are slower than the C version by factors
of greater than 1000. This is excessive. LISP interpreters do a bit
better, but still don't reach 1/10 of C. What interpreters do a decent
job on computation?

Someone else correctly pointed out that Macintosh Common Lisp (MCL),
which is not at all known for its floating-point optimization relative
to Common Lisp implementations on other platforms, already does
considerably better than you cite. But of course, MCL, like most
commercial Common Lisp implementations, compiles all the way to
machine instructions. Therein lies your answer, and that is why I
have added comp.lang.lisp to this followup. You don't need an
"interpreter" per se, you need an Object-Oriented Dynamic Language
(OODL); and of those, Common Lisp best meets your performance
requirement among industrial-strength commercial languages,
particularly if you add appropriate (but optional) type declarations
in those rare "hot spots" such as your example above.

--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.