This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: GUILE projects
Telford Tendys <telford@eng.uts.edu.au> writes:
> Thus, if a bytecode system has an instruction for a 16 bit relative
> branch while the tree follows a 32 bit absolute pointer, the bytecode runs
> twice as fast despite the extra calculation involved. If the bytecode
> is arranged so that blocks of instructions stored close to each other
> are typically executed together then it gets the advantage of a chunky
> fetch from memory (many systems use 64 bit or 128 bit data paths to memory,
> and burst reads, so reading a few widely spaced words is slow).
Early guile had a bytecode compiler. It was abandoned because it was
(IIRC) 20% slower than the current evaluator. The reason for this is
that you generally read the trees in a large chunk, and so the cells
tend to be allocated together. So either way you end up with a
reasonably good locality.
It is interesting to note that current module system conses lots of
garbage during loading. This could account for somewhat lower
benchmark speed compared to SCM (as you allocate several garbage cells
between every two cells that are live code).
--
How to eff the ineffable?