From: Lawrence G. Mayka
Subject: Re: Why are intepreters so slow today
Date: 
Message-ID: <LGM.94Apr16161343@polaris.ih.att.com>
In article <···············@netcom.com> ·····@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
        ···@ieain.att.com

Standard disclaimer.