This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GUILE projects


> I don't think that implementing a byte-code machine that is close to a
> real cpu would be worthwhile.  The current treecode evaluator might be
> very tight, but it is conceptually simple because it is close to
> Scheme.  The rewriting of a `let' form into the internal memoized code
> is straightforward and the execution of it, too.  Compiling into code
> for a register machine is probably much more involved.  We don't need
> to abandon these nice properties of treecodes.

You might want to take a look at ``oaklisp'' which is a bytecode based
LISP that is rather similar to Java (and earlier than Java, and Sun's
original project name for Java was oak, hmmm) and oaklisp has a very
small kernel written in C that is quite neat. However, it is a very different
internal structure to guile and switching over would be a bit of work.

> I expect the position-independent, read-only treecodes to be slightly
> slower than the existing one because they will like require more
> indirections to get at global variables, for example, but hopefully
> the other benefits (like being easier on the GC and allowing more
> optimizations) will compensate.

A lot of people count CPU clocks which is old-school thinking. Most modern
CPUs run 5 times faster than their memory so they depend on cache. Most
data structures don't fit into cache or they are thinly distributed trees
and the cache is optimised to handle chunkular data so the result is that
your memory bandwidth controls the execution speed.

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

	- Tel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]