[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: status: separation of expansion/optimization/memoization/execution
From: |
Rob Browning |
Subject: |
Re: status: separation of expansion/optimization/memoization/execution |
Date: |
Fri, 02 Aug 2002 18:15:21 -0500 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) |
Dirk Herrmann <address@hidden> writes:
> Basically, with the changes above everythings still works as before,
> that is, expansion and friends are still executed dynamically during
> execution. However, the functionality of each of the
> builtin-mmacros is more cleanly separated into different tasks with
> different responsibilities. And, I have added more exhaustive
> syntax checks into the expand_foo functions.
Eeeeexcelent :>
> The effect so far is, that booting guile takes noticably longer (at least
> 15%), but for example executing the test-suite is almost as fast as before
> (2% slower). Unfortunately, it is not yet possible to achieve large
> performance improvements. This will only be possible when the steps are
> really separated. Then, memoizing variable locations in the memoize_foo
> functions will be possible, which simply can not work at the moment: One
> reason is the re-writing of internal defines, which disallows the
> memoization of variables until the expansion phase is completed.
I don't know if you *are* worrying about the performance cost right
now, but if you are, I'd say don't. Even if guile stays 20% slower
for a while, the long term benefits (and potential speedups) of this
work far outweigh the medium-term performance cost.
BTW has anyone else played with valgrind
http://developer.kde.org/~sewardj/docs/manual.html? I'm planning to
play with it, but so far have only had a chance to see that it doesn't
like some of our ptr manipulations. I also wonder if cachegrind might
be able to tell us anything useful...
> I have, however, not taken care of keeping track of debugging
> information so far. That is, I would like to hear suggestions about
> how this should be done, since I don't have looked into that issue
> yet. If someone is interested to give the stuff a review (with
> respect to the debugging issues or just generally), I would be glad
> to send you the patches for eval.c and eval.h.
I don't really know a lot about how debugging's being handled now, so
I'm not the best person to comment here.
> If the debugging stuff is worked out, it could even make sense to
> submit the changes so far to allow for a broader testing in the head
> branch.
Absolutely. Actually I'd even say that if the debugging info is not
worked out, but if we think it *can* be worked out within a couple of
months, and if everything else is OK, then perhaps you should go ahead
and merge. Your work will definitely get more attention in HEAD.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
Re: status: separation of expansion/optimization/memoization/execution, Neil Jerram, 2002/08/05