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 (email@example.com)