>> Performance-wise, the Scheme part of STk is a dog; my rule of thumb is a
>> factor of 100 slower than native code on programs that do a lot of...
>
> A dog? My understanding of the relative performance of
>different _interpreted_ languages lead me to believe that scheme (and
>therefore STk) should be relatively efficient---please correct me if I
>am wrong! Of course it will always be slower than compiled C code (is
>this really what you were comparing it to when you say "native code")
>but when compared to other interpreters (and especially Tcl) it stacks
>up significantly better.
Sorry, I was not making myself clear. What I ment to say was, STk's
Scheme interpreter (or: STk's implementation of Scheme, as opposed to
its implementation of Tk or regexps or whatever) is a dog, relative to
other Scheme systems that I use (Chez Scheme and MIT Scheme, largely,
which admittely is harsh competition).
Scheme can indeed be efficiently executed, in many forms. In rough
order of performance for a given benchmark, some of these forms may be:
interpeting a minimally preprocessed Scheme syntax tree like STk and
scores of others; compiling to a portable bytecode which is then
interpreted, like Scheme 48/scsh and MacScheme; compiling to C and
compiled by your friendly C compiler, like Scheme->C and Gambit-C; or
compiling directly to machine code like Chez Scheme, Orbit, MIT Scheme,
MacGambit, and several others. The latter group contain what I
previously referred to as "native-code" systems, although the
Scheme-to-C translators are arguably native-code as well.
One of my soapboxes is that in almost no cases should we be talking
about interpreted _languages_, only about interpreter _implementations_
of a language. It's a technology thing, an implementation issue, not a
language issue, whether your Scheme system is an interpreter or not.
Most languages can be compiled, and most of them fruitfully
(performance-wise), and there are high-quality Scheme systems out there
that do not have interpreters (Chez Scheme, for example). An
interpreter is simply a low-cost implementation technique.
--lars
Received on Mon Aug 05 1996 - 04:01:16 CEST
This archive was generated by hypermail 2.3.0
: Mon Jul 21 2014 - 19:38:59 CEST