This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: librep's indirect threaded bytecode interpretter
- To: Guile Mailing List <guile at sourceware dot cygnus dot com>
- Subject: Re: librep's indirect threaded bytecode interpretter
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Tue, 23 May 2000 09:30:05 +0200 (MEST)
Mikael Djurfeldt writes:
> Personally, I now suspects that a byte-code interpreter can be faster
> than a tree interpreter ever can be.
I don't know enough about properties of byte code and tree code
interpreters, thus I can't tell which is _generally_ faster. I believe,
though, that however code is finally to be stored, in any case a
preprocessing phase can get quite a lot more out of the code than guile
currently does. Thus, the following points are independent of the way the
compiled code is stored, but could apply to both variants, and none of
them is performed currently.
- evaluation of constant expressions (+ x 1 1) --> (+ x 2)
- no argument checking if the arguments are _known_ to be OK. Currently
arguments are checked _within_ each primitive, thus even if a clever
compiler can determine the types before a function is applied, it could
not eliminate the type checks. Goops may reduce that problem by some
amount, since with goops, argument checking is performed _outside_ of
the function itself.
- the _number_ of arguments for some function application is mostly fixed,
since it is encoded syntactically in the code in most
cases. Nevertheless does the current evaluator check this number over
and over.
- storing code outside of the heap. Again, whether this is done as tree-
or bytecode is not important. But code stored in the heap leads to
longer garbage collection time - even with gengc, although then it
becomes less important.
Thus, I am not sure if "bytecode vs treecode" is the problem that is to be
addressed here. It's rather "preprocessed vs non-preprocessed".
Best regards
Dirk