Hi Neil, Neil Jerram <[EMAIL PROTECTED]> writes:
> These sound really interesting! Do we need to wait for a rewrite of > the core interpreter, though, or could we try doing this in the > current code? The current code is very tricky to work with. I once tried to change environments to use vectors instead of lists so that `scm_ilookup ()' would become O(N), but it proved hard to do and I eventually bailed out (IIRC the issue that stopped me had to do with rest arguments handling, currently handled by `SCM_CDRLOC', which assumes that a frame's variables are contained in a list, if you see what I mean). >> * heap-allocation-free closure invocations, which can be achieved by >> storing a closure's arguments into a stack-allocated C array or, >> even better, in registers (of course, invoking closures with rest >> arguments would still require allocating an argument list); >> >> * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where >> N is the frame number and M the position of the variable within that >> frame's environment; > > Are you sure the current algorithm is O(N*M)? I would have said > O(N+M). Oh yes, you're right (these are two non-nested `for' loops). >> * no C function call overhead for tail(-recursive) calls. > > I thought that was mostly achieved already, by extensive use of > gotos. But I guess there must be important cases that I've not > noticed. You're right too. :-) Anyway, it looks like there are opportunity for performance improvements, and that could be an opportunity to switch to a compiled-to-C meta-circular interpreter (as seen in SICP). (It looks like I'm "dreaming" too much compared to my free time, but I hope others could adopt the idea!) Thanks, Ludovic. _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
