This is the mail archive of the
mailing list for the Guile project.
Re: Is guile byte-code compiled?
Michael Vanier <email@example.com> writes:
> I wonder why one was chosen over the other... was this the way SCM did
Yes, Guile's interpreter is very similar to the interpreter of SCM
> I hope that guile doesn't get stuck with a sub-optimal solution if
> byte-code interpretation could in principle make things faster.
While it is possible that byte-code interpretation could in principle
be faster, no-one has succeeded to beat SCM's "tree-evaluator". (SCM
has recently beaten Guile, but that is easy to catch up with.)
> As you point out, thought BC isn't a panacea, and I'd like to
> understand more about the tradeoffs.
Since Guile is supposed to be an application scripting language you
don't want it to be too large. If you use BC, you need both a BC
compiler and a BC interpreter, which increases the size of the
system. (Look at Scheme48 or RScheme. They are really huge compared
A BC system also needs to do more work when loading code. Guile only
modifies some parts of the code tree, and it does this lazily, which
means that evaluation can start immediately---a little slow the first
time it evaluates a piece of code, but not extremely much slower than
at the second time when it runs with full speed.
(One silly thing is that although Guile is built to load code fast and
*could* do it, code loading is extremely slow due to the design of
the current module system.)
To summarize: Just as SCM, Guile tries to minimize the combined costs
of size of implementation, code loading speed, and evaluation speed.
It succeeds well: It is smaller than BC-based systems, it is faster
than BC-based systems, and, it would load code faster if only we
replaced the current module system and decreased the amount of code to
evaluate at startup.