Hello! Andy Wingo <[EMAIL PROTECTED]> 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
