Re: Why are intepreters so slow today

Markus Freericks (mfx@cs.tu-berlin.de)
15 Apr 1994 09:43:39 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?

John Nagle
Hello John,

first a comment: your benchmark is not so much a "computation" benchmark
than a "control" benchmark; i.e. there are two integer (+,>) and control
(jump-on-flag) ops to the one floating-point addition. In general, the
best use of interpretive and extension languages is made by utilizing their
features of "high abstraction" (associative arrays, file ops, etc.).
When counting bits, there is no alternative to C (or even assembler).

If you need an extension language, I recommend the excellent ELK scheme
interpreter. The comp.lang.scheme FAQ should tell you where to find it. ELK
is nice in that you can intermix it with C, i.e. your own C functions
can be used as "primitives" in scheme programs; and scheme expressions can
be evaluated by C functions.

Hope that helps,
Markus

-- 
Markus Freericks         mfx@cs.tu-berlin.de        +49-30-314-21390
TU Berlin Sekr. FR 2-2, Franklinstr. 28/29, D-10587 Berlin (Germany)
		"Inertia makes the world go 'round."