gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] 2.6.2


From: Camm Maguire
Subject: [Gcl-devel] 2.6.2
Date: 20 Mar 2004 14:02:21 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  This is just a summary progress note toward the stable
release.

1) I've just committed the compiler performance improvements I
   mentioned earlier.  These should only really be apparent on big
   compiles, like Paul's tester or axiom.  In addition, a number of
   unnecessary gbc churning bits -- like comparing bignums to fixnums
   within the inner loops in gcl_seqlib.lsp, and allocating two
   strings per gensym, have been fixed.  Support for declarations of
   the form (declare ((vector t) foo)) are now supported, enabling the
   optimizations that accrue in such cases.  Once items like this are
   in place, GCL can produce quit fast code.  If anyone would like to
   look at a sample, check out gcl_cmpinline.c

   The principal reason for adding this to stable is so that we can
   report results of Paul's random tester in the release notes.

2) GCL's compiler has an info structure for each form which maintains
   lists of changed and referred variables.  These have been replaced
   with sorted arrays.  While lookups are fast, this introduces the
   issue of expanding the array size.  I groped around quite a while
   on this, until (I think) I figured out the 'lisp way' to do this --
   make your arrays twice as large and use fill pointers.  This is
   what is implemented now.  Prior to this, I developed an uglier
   alternate route which would let the user define a padding variable,
   and actually allocate larger space than requested, redirecting
   adjust-array request to a simple array resize when appropriate.
   The spec for adjust-array seems to indicate that caching algorithms
   like this could be deemed useful.  It does allow one to write
   simpler lisp to achieve the same effect as with fill pointers, but
   other than this there is not much advantage to the feature that I
   can see.  I've therefore not committed this.  It will not go into
   stable in any case, but if anyone feels this could be useful in a
   way I cannot see, I'll add it to unstable.  Otherwise I might just
   post the patch to record the work in the mailing list archives
   should it ever be needed.  Interestingly enough, axiom can benefit
   from this array caching quite a bit as well.

3) Remaining issues are quite few.  There is one potential item, again
   revealed by Paul's tester, which I'd like to ensure is correct
   before release, and this regards the behavior of the memory
   management system when allocating the last pages possible from the
   maximum.  I am not sure this is handled gracefully.  Running Paul's
   tester with 10000/8 can actually generate occasional forms which
   require close to our current max of 512Mb.  The good news is that I
   have been unable to generate a form showing *any* compiler error
   thus far, but have occasionally run out of memory, including having
   the OS kill the underlying gcc.

4) To my knowledge there is only one other outstanding issue, and that
   is the Windows crash during the ansi test suite.  I'm assuming that
   both the filename corruption and the build failure reported
   elsewhere arise from Windows system setup issues, or are no longer
   present.   Please correct me if wrong.

5) It would be great if someone could volunteer to write some release
   notes.  There's been a lot of work behind this release, and quite a
   few achievements of which I think we can all be proud.  To this
   end, perhaps we could generate a little table showing gcl's status
   per platform.  The regression-like tests we have at our disposal
   are (to my knowledge): self-compile, random-integer-form tests,
   ansi-tests, maxima build, maxima regression, acl2 build, acl2 book
   certification, axiom build, axiom test suite, nqthm-1992 and
   pc-nqthm-1992 and the 'giant-tests' thereof.  Perhaps we can make a
   little html table with a row for each gcl platform and a green
   yellow, or red box or some such indicating the test status.
   Volunteers to provide this information for the platform of their
   choice most welcome.  It would also be useful if someone could go
   through the changelogs and summarize the key achievements.  Again,
   this is entirely optional, only if anyone has time.

6) Mike has some checkins he wants to go in on Monday.  I hope to have
   the gc mystery resolved by then.  Then I suggest we make a
   non-branch tag in cvs, 2.6.2pre, and let everyone build and test
   the exact same version.  If there are no problems, we will tag the
   same code 2.6.2, and push to ftp.gnu.org.  Any thoughts or
   suggestions on this plan are also most welcome.

Take care,

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]