Re: Trying to understand chicken limitations

[felix . winkelmann]

> > All of these Schemes start up instantly and due to their simplicity
> > are the easiest to embed into C with no external dependencies. Their
> > internals are easy to modify as needed. But they are also the slowest
> > interpreters available. They don't even have a bytecode compiler; they
> > store your procedures as lists and recurse through the lists each time
> > you call the procedure. Chicken, Chibi-Scheme, etc. have bytecode
> > interpreters that are almost certainly faster if your Scheme code has
> > loops with lots of iterations. However, they are also more complex.
>
> this is off-topic, but i'm very curious about this. i would really
> appreciate any feedback.
>
> is a bytecode interpreter faster (all things being equal) than one which
> stores procedures as lists?  even with loops and iterations, assuming
> the code was was only lexically analyzed once as in "The Structure and
> Interpretation of Computer Programs"?
>
> i would think the eventual speed of a byte compiler comes from all the
> optimizations that are possible.
>

It depends on the simplicity of the language semantics and how well they
map to the execution engine. Bytecode-compilers allow some optimizations
and are the most widely used approach, even if not necessarily the best.

IIRC, Pico Lisp uses a direct interpreter and is very fast. I think SCM also
used direct interpretation of s-expressions and was among the faster systems,
back in the days. Even earlier, LeLisp was famous for its speed and was
interpreted, but I don't know what strategy it used.

Note that CHICKEN uses the Lapalme/Feeley approach, not a bytecode
intepreter, as described in Marc's reply, a techinique which is extremely 
elegant,
simple and concise.


felix