Re: status: separation of expansion/optimization/memoization/execution

From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-devel@gnu.org, guile-user@gnu.org
Subject: Re: status: separation of expansion/optimization/memoization/execution
Date: Fri, 02 Aug 2002 18:15:21 -0500	[thread overview]
Message-ID: <87sn1w6eeu.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <Pine.GSO.4.05.10208022349150.5209-100000@sallust.ida.ing.tu-bs.de> (Dirk Herrmann's message of "Sat, 3 Aug 2002 00:42:21 +0200 (CEST)")

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> 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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel