Re: Why are intepreters so slow today

Oliver Laumann (net@cs.tu-berlin.de)
15 Apr 1994 10:28:18 GMT

In article <2olk40$a55@news.cs.tu-berlin.de>,
Markus Freericks <mfx@cs.tu-berlin.de> 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.
>
> If you need an extension language, I recommend the excellent ELK scheme
> interpreter.

If the author is interested in a speed of 1/10 the speed of compiled C
code, then Elk definitely isn't the right tool. I don't think he well
find a Scheme interpreter at all that is capable of an execution speed
like that. If he would like to use Scheme as the extension language
*and* needs the speed, a decent Scheme compiler is the only choice
(there are several, although they are probably not well suited as an
extension language).

I don't quite understand why an extension language implementation has
to be that fast anyway. The time-critical parts of the program
(usually just a small portion of the code) can always be re-written in
the underlying application's implementation language (such as C or C++)
to gain performance. Look at GNU-Emacs. Emacs-Lisp is slower than a
snail's pace, yet that doesn't seem to be a major problem for the
typical Emacs extension.

[Ob-plug: If you want a Scheme-based extension language with dynamic
loading of object files, full `unexec', Xlib, Xt, Athena widget, and
Motif interfaces, a UNIX extension, and generational, incremental
garbage collection, then you might want to look into Elk.]