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: Release now? Date: Mon, 24 Feb 2003 12:35:02 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87smudcysp.fsf@raven.i.defaultvalue.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046112121 2932 80.91.224.249 (24 Feb 2003 18:42:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2003 18:42:01 +0000 (UTC) Cc: Marius Vollmer Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18nNY6-0000l6-00 for ; Mon, 24 Feb 2003 19:41:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nNWm-0000TG-00 for guile-devel@m.gmane.org; Mon, 24 Feb 2003 13:40:36 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18nNWE-0000OG-00 for guile-devel@gnu.org; Mon, 24 Feb 2003 13:40:02 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18nNWC-0000Ms-00 for guile-devel@gnu.org; Mon, 24 Feb 2003 13:40:01 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nNRQ-0007e5-00 for guile-devel@gnu.org; Mon, 24 Feb 2003 13:35:04 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 9023F13B5F; Mon, 24 Feb 2003 12:35:02 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 88544CFE96; Mon, 24 Feb 2003 12:35:02 -0600 (CST) Original-To: Mikael Djurfeldt In-Reply-To: (Mikael Djurfeldt's message of "Mon, 24 Feb 2003 13:37:33 +0100") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Original-cc: guile-devel@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1962 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1962 Mikael Djurfeldt writes: > When Rob has added the GMP support there's only the signal handling > left of the major changes intended for the 1.8 release, right? Well, the GMP support isn't in the tree yet. I'm actually trying to evaluate it and was planning to send a message to guile-devel about it today. Stay tuned. Although I agree that shorter release periods might be a good idea, I'd be more likely to shoot for say once or twice a year for major releases unless we have good reason to do otherwise. Of course I'm not sure this contradicts what you're suggesting. However I do feel that trying to release in the next month or two would be a little early. Guile 1.6 isn't even in Debian yet, although I warned the other relevant maintainers last week that I'd be moving it from the staging area to unstable at the start of this week (i.e. I'll be uploading to unstable shortly). Once it does go into unstable, if history is any guide, it'll still be a while before all the relevant maintainers have even finished shifting over and uploading new packages. If we can afford it, I'd tend to argue in favor of at least some period of stability, to let this version "settle". This concern by itself wouldn't necessarily be enough to argue in favor of waiting a while, but I'd also like to wait until we get the performance of 1.7 to be more comparable to 1.6. I believe the recent macro system cleanups have cost us quite a bit of performance, and while I still think they're absolutely the right thing to do, I'd like to get them completely finished (where do we stand? do we still have "execution-time" expansions?), and then work on performance a bit. I've been spending quite a bit of time over the past few weeks trying to figure out what possibilities might be available to us wrt to performance going forward, once we have macroexpansion separated from evaluation, including an interesting discussion with one of the gcc maintainers :> As an example of the performance issue, the following test just takes 400000 pre-generated random bignum pairs and applies a given operator to each of the pairs, ignoring the result. Note that this is a quick-hack benchmark-wise, and so feel free to criticize it as such :> The core code: (define (bench-random-int-op op) (let loop ((x-vals random-x-values) (y-vals random-y-values)) (if (pair? x-vals) (begin (op (car x-vals) (car y-vals)) (loop (cdr x-vals) (cdr y-vals)))))) The results: $ ./run-benchmark guile-1.6 ./guile-1.7 foo.scm starting trials ("bench-random-op +" "guile-1.6" ((user . 199) (sys . 0) (gc . 89))) ("bench-random-op -" "guile-1.6" ((user . 178) (sys . 0) (gc . 57))) ("bench-random-op *" "guile-1.6" ((user . 220) (sys . 0) (gc . 101))) ("bench-random-op /" "guile-1.6" ((user . 264) (sys . 0) (gc . 118))) ("bench-random-op gcd" "guile-1.6" ((user . 123) (sys . 0) (gc . 43))) ("bench-random-op lcm" "guile-1.6" ((user . 278) (sys . 0) (gc . 119))) starting trials ("bench-random-op +" "./guile-1.7" ((user . 341) (sys . 1) (gc . 61))) ("bench-random-op -" "./guile-1.7" ((user . 315) (sys . 0) (gc . 60))) ("bench-random-op *" "./guile-1.7" ((user . 352) (sys . 0) (gc . 55))) ("bench-random-op /" "./guile-1.7" ((user . 382) (sys . 0) (gc . 54))) ("bench-random-op gcd" "./guile-1.7" ((user . 267) (sys . 0) (gc . 56))) ("bench-random-op lcm" "./guile-1.7" ((user . 374) (sys . 0) (gc . 54))) Also, with respect to a comment you made to Dale later on: > If we then initiate the release process, chances are that the > release won't happen until summer, so 1.6 will have at least half a > year of "life". So, "now" means "in half a year". But if we don't > start to plan for it now, it will be longer... Though I can definitely see why you'd be concerned about this, I'm hoping to handle the next release somewhat differently than the last one. I believe I unintentionally branched too early last time, and that contributed quite a bit to the delay. This time I don't want to branch until *much* later in the process. I'd like for us to all work to get things to a state where we think we're just about ready to release and then branch. I believe that will let us move much more quickly. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel