Re: Why are intepreters so slow today
Seth Breidbart (firstname.lastname@example.org)
20 Apr 1994 00:03:09 -0400
In article <email@example.com>, Seth Breidbart <firstname.lastname@example.org> wrote:
>In article <nagleCoACH4.email@example.com>, John Nagle <firstname.lastname@example.org> 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. 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?
>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.
In fact, there's another advantage to the APL: it's adding up the
elements of an array, equivalent to replacing the second line of the C
for (i = 0; i < 1000000; i++) x = x + y[i];
which will be slower (in compiled C) than the original expression.