Re: What happened to the ex-Guile VM?

[Marius Vollmer]

Keisuke Nishida <address@hidden> writes:

> I found somebody was working on a bytecode interpreter (VM) for
> Guile around 1997.

Was this the coupling of Guile to a Java Virtual Machine, "Latte"?

> What happened to it?

I don't know.

> Anyway, this is a brief summary of the current status of my VM.

Thanks!  This sounds *very* interesting!

I'm quite in favor of replacing the current evaluator with a `better'
one.  `Better' is a complicated requirement here, since so many
fcators are involved.  Speed, of course, but not only speed.
Maintainability, speed of loading code, debuggability of the executed
program, portability, easy of hacking it (to implement new
optimizations, say), interactive responsiveness, standards
conformance, and probably more.

In my opinion, the current avaluator fares like this:

- Speed.  Not too bad, but it takes a considerable hit because it
  conses so much.  A different model can improve on this, by using a
  stack discipline for allocating most environment frames.  I think
  SCM now has something like this.

- Maintainability.  Very bad.  I find it generally quite hard to find
  the right way to fix bugs in it and to have a good idea of the
  consequences of a change.

- Speed of loading code.  Quite fast, considering that it loads source
  code and `compilation time' is included in the load time.  This is
  what the evaluator is optimized for, I'd say.

- Debuggability.  Very good, thanks to Mikaels `Debugging' version of
  the evaluator, but I find the split into two evaluators kind-of
  awkward.  Conceptually, I would like a design better where we have
  only one evaluator, and explicitely instrument the code for
  debugging.  Or maybe not.  The current method of having a single
  source fot the evaluators (that is compiled twice) is certainly no
  maintainability problem.

- Portability.  Very good.

- Ease of Hacking.  Bad.  I would like a more explicit separation into
  compilation and execution phases much better, where the compilation
  phase does not need to be fast and can be clean instead.

- Interactive responsiveness.  Good, since it compiles so fast and
  compilation is transparent.

- Standards conformance.  Only minor things that can be considered
  bugs.  The big things like general tail-call elimination and
  continuations are there.

I think the central thing that I want is a framework that has room for
a real compiler that can afford the be clean and sophisticated.
Interactive responsiveness will suffer when we only have such a
compiler, but it can probably be made reasonably fast enough when
optimization settings are low, and we can probably still compile
top-level functions on demand (on their first call).

The thing that irks me most with Guile is that large applications,
consisting of a large body of Scheme code, are `compiled' from source
every time they load although the source doesn't change at all for
most of their users, ever.

I would be happy with a system that separates the current memoization
from the execuation, that makes memoized code a data type that does
not need to hide in the innards of Guile, and that allows the saving
and loading of memoized code.  This system could be incrementally
evolved from the current Guile.  But since we have very attractive
candidates for a VM, this is just an idle thought.


Anyway, this is all just from the top of my head.


As to a future integration of your VM into Guile, I'd say that it
would simplify things a lot when you try to keep the many different
improvements in guile-vm as separate (or `orthogonal') as possible.
That is, it will much easier to switch to your VM, when we don't also
have to switch to your module system.  Or the other way around.

It will also be important to know how stanards conforming your VM is.
Does it handle continuations correctly?

> Let's see the execution speed in a simple recursion:
> 
>   % guile  ;; debug evaluator
>   guile> (define (fib n) (if (< n 2) 1 (+ (fib (- n 1)) (fib (- n 2)))))
>   guile> (time (fib 30))
>   clock utime stime cutime cstime gctime
>   23.81 23.53  0.14   0.00   0.00  12.76
>   $2 = 1346269
> 
>   % guile-vm  ;; debug engine
>   address@hidden> ,time (fib 30)
>   $3 = 1346269
>   clock utime stime cutime cstime gctime
>    3.12  3.11  0.00   0.00   0.00   0.00

Nice!  With Lightning and hand coding the assembler (probably
pessimizing it on the way), I get a speedup of 28 compared to the
debugging evaluator and 11 compared to the normal evaluator.  Since
you get a speedup of about 7.5, this speaks very much for your VM.

>   % bigloo -O6 fib.scm ;; version 2.2b
>   % time a.out
>   1346269
>   real        0m0.271s
>   user        0m0.240s
>   sys 0m0.020s

This is impressive.  This is a speedup of 88.  A hand-coded fixnum
only Lightning version of fib gives a speed up of about 230.  Does
bigloo use generic arithmetic?