Re: Why are intepreters so slow today

William Chang in Marr Lab (
18 Apr 1994 14:38:37 -0400

In article <2osv3k$> (Seth Breidbart) writes:
>In article <>, John Nagle <> wrote:
>> 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...

I think you are underestimating the interpretive overhead. Even for
loopless APL, 1/10 is very hard to achieve. My experience with two
small pieces of loopless code are: (integer intensive) 1/50 on an RS/6000
and (byte intensive) 1/20 on a Mac. The (non-APL) interpreters I have used
are much, much slower because the code has to be loopy. Another order of
magnitude at least. (Aside, I once used a C interpreter called SaberC
for debugging; it was useless (then) for "real" bugs because programs
would have taken hours to run.)

Can you post the times for +/1000000 rho 1.0, and the speed of your Mac?

In APL.68000II (which was written in assembler) it takes 6 seconds on a
Mac Powerbook 180c with 33 Mhz 68030. (Same time if 1.0 is replaced with 1.1)
One second out of six is spent creating the array.

>>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?
>Have you tried APL? I don't have a mac, but an equivalent expression
>(using APL properly, +/1000000 .rho 1.0 ) should run at least as fast
>as compiled C.

We will know soon enough if John posts the times... (But I doubt it.)

-- Bill Chang (