Re: further guile-vm integration

[Ludovic Courtès]

Hello!

Andy Wingo <address@hidden> writes:

> The `vm' branch in the guile repo is coming along nicely. It fully
> self-compiles, passes test suites, has a really useful repl, etc etc.
> There are some problems with call/cc that will be fixed in the future,
> but it's mostly correct.

Thanks for the great news!  :-)

>   1. Make module compilation and load-compiled work out "of the box".
>
>   This means that you should be able to make .go files for any module,
>   normally as a part of package installation, and they should be
>   loadable by guile without any problems or extra configuration.

Actually `.go' loading support has been in `boot-9.scm' "forever".  ;-)

Besides, do you have an automatic compilation approach in mind (à la
Python) or something explicit, possibly with source/binary time-stamp
comparison?

The latter looks more "user-friendly" to me but wouldn't be as
transparent.

> So I'm going to work on moving the source files over to the libguile/
> directory, and to start thinking about the modules. I like that
> guile-vm's modules are in a separate namespace (well two, actually --
> (system ...) and (language ...)), but I do not intend to move ice-9
> things into that hierarchy, to avoid breaking existing code.

Agreed.

> Let me know if you have thoughts about this plan! My hope would be that
> once there are no or very few and solvable regressions, we could merge
> this to master and call it 1.10 or 2.0.

Did you benchmark the thing?  I remember speed improvements were not all
that clear back when I played with Guile-VM.

Besides, before making a release, it may be worth thinking about
potential GO format changes that we'd possibly want to make in the
future.  One big thing I had in mind was the use of word-aligned
bytecodes, which should improve performance on several architectures
(accessing data that's not aligned on a machine-word boundary is costly
on RISC architectures, and you end up loading a full machine word
anyway; on Intel, it appears to improve cache performance [0]).  Using
only fixed-size bytecodes might even be an option, as it would simplify
the bytecode interpreter, potentially making it faster as well.

Thanks,
Ludo'.

[0] http://softwarecommunity.intel.com/Wiki/Performanceoptimization/502.htm