-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andy Wingo wrote: > Greets! > > So, yes, it's Saturday night: but I do love Guile hacking so. (Also: my > partner is away.) So a VM status update it is! > > * The parts of the instruction stream that are mapped directly to > "struct scm_objcode" are now aligned to 8-byte boundaries, and > written in native endianness. > > * Much more source information propagates through the compiler and > into the metadata now. In short, whereas before it was "expressions > are only marked as coming from a source location if they are eq? to > an expression read in by guile", now it is "expressions are marked > with the source location of their containing expression, unless they > are eq? to an expression read by guile". > > The upshot is that original source information is preserved to a > much broader extent than before, as macro-expanded or transformed > expressions all have some kind of anchor to the original source. > > Another ramification of this is that procedures have source > information corresponding to where they were really defined, in > addition to locations of their subexpressions. (program-source foo > 0) will give you that. > > * The in-bytecode metadata representation has been compressed. Now we > associate bytecode offsets with line-column pairs, and only record > that information when it changes. The idea is, byte N in the > instruction stream corresponds to source info for byte M, where M <= > N. Also, we only record the filename when it changes. > > This means that we can have more source information, as mentioned > above, but still have objcode files of similar size. > > * The VM dispatches to signal handlers (asyncs) more often, > specifically: on return from a call, just before a call, and on a > tail call. > > * Stack captures are much more reliable. Before there were some bugs. > This allows statprof to work properly, capturing the whole stack up > to a common root. > > * I set out to optimize GOOPS, and ended up writing a new call tree > visualizer: > > > http://wingolog.org/archives/2009/02/09/visualizing-statistical-profiles-with-chartprof > > It turns out that most of the time loading GOOPS is in the compiler, > which comes from those dynamic recompilation bits I mentioned in the > past. So I focused on optimizing the compiler -- it is much faster > now. > > But still, for the uses that GOOPS has, a closure is better than a > compiler. I changed thing in GOOPS so that it doesn't compile at > runtime any more, and now on this machine GOOPS loads in something > like 40ms. That's pretty good! Though improvements are possible, of > course. > > * The VM now has support for separate engines. Currently the engines > are just "regular" and "debug", defaulting to "debug". There are not > interfaces to change this at runtime, yet. But it turns out there's > not much difference. See vm-engine.c for more details. It seems that > native compilation would be much better than a "reckless" engine. > > Well, that's about it as far as changes go. And as far as status? I'm > going to update the docs for changes in the last month, then talk > seriously about a merge to master. I think it's ready. > > Happy hacking, > > Andy > > ps. Guile finally loads faster than Python now. It's about time...
Always a pleasure to read your updates. Thanks, Marijn ps Kill, kill the snake ;p - -- Sarcasm puts the iron in irony, cynicism the steel. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML <http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkmZUmEACgkQp/VmCx0OL2yoBgCYzGAJt3+u+OBBpWdsQt9RaYlR ygCdFRv7CQr+ed0Q/gz5X6nL0Zy3xuo= =yzOq -----END PGP SIGNATURE-----
