Re: Release now?

[Rob Browning <rlb@defaultvalue.org>]

Mikael Djurfeldt <mdj@kvast.blakulla.net> 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