Re: Is guile byte-code compiled?

[Greg Harvey <Greg.Harvey@thezone.net>]

Mikael Djurfeldt <mdj@nada.kth.se> writes:

> Michael Vanier <mvanier@bbb.caltech.edu> writes:
> 
> > I wonder why one was chosen over the other... was this the way SCM did
> > things?
> 
> Yes, Guile's interpreter is very similar to the interpreter of SCM
> 4cx.
> 
> > 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
> to Guile.)

All you need is a core with a normal code and a byte code interpreter
(which I guess falls down to two evals... I can't see how this would
be major bloat, given that we've got pretty much everything else under
the sun ;). The bc can be in a separate module. 

> 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.

You can compile everything when you load, but that's a fairly lousy
way of going about things (unless you automatically save the compiled
code the way python does... I find that really annoying, though). Pre
compiled code will load faster, for the simple reason that it doesn't
have to do as much parsing.

The greatest benefit of a compiled system is that it can do expensive
analysis of the code, which you can't really do in an interpreter (and
some stuff... goops & (particularly) the gc come to mind, could really
get a kick from having more information... though it would be much
more useful to have a native code compiler). Admittedly, a naive
scheme->bytes isn't very useful.

In the end, all you care about is that the code runs well, whether it
goes by interpreter, compiler, or dispatching steroid-enhanced carrier
pigeons. 


> (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, 

A poorly written bc; there's no reason a bc interpreter can't
implement the same optimizations as the current interpreter, as well
as compiler optimizations. The thing is, is it worth the effort (or is
it better to work on making hobbit more simple to use... no offense to
Bernard Urban :), and (more importantly) is anyone really itching to
do it?

> and, it would load code faster if only we
> replaced the current module system and decreased the amount of code to
> evaluate at startup.
> 
> /mdj
> 
> 

-- 
Greg