From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: status: separation of expansion/optimization/memoization/execution Date: Fri, 02 Aug 2002 18:15:21 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87sn1w6eeu.fsf@raven.i.defaultvalue.org> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028330131 22162 127.0.0.1 (2 Aug 2002 23:15:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 2 Aug 2002 23:15:31 +0000 (UTC) Cc: guile-devel@gnu.org, guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17aldp-0005lK-00 for ; Sat, 03 Aug 2002 01:15:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17aleO-0007xn-00; Fri, 02 Aug 2002 19:16:04 -0400 Original-Received: from dsl-209-87-109-2.constant.com ([209.87.109.2] helo=defaultvalue.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17aldj-0007wG-00; Fri, 02 Aug 2002 19:15:23 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 3F2D0EC59; Fri, 2 Aug 2002 18:15:22 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 34B931DAF; Fri, 2 Aug 2002 18:15:21 -0500 (CDT) Original-To: Dirk Herrmann In-Reply-To: (Dirk Herrmann's message of "Sat, 3 Aug 2002 00:42:21 +0200 (CEST)") Original-Lines: 55 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:937 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:937 Dirk Herrmann 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