[Top][All Lists]
[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
- [Gcl-devel] Re: PLT code and Mach-O, (continued)
- [Gcl-devel] Re: PLT code and Mach-O, Camm Maguire, 2004/03/11
- [Gcl-devel] Re: PLT code and Mach-O, Vadim V. Zhytnikov, 2004/03/11
- [Gcl-devel] Re: PLT code and Mach-O, Camm Maguire, 2004/03/11
- [Gcl-devel] Re: PLT code and Mach-O, Vadim V. Zhytnikov, 2004/03/13
- [Gcl-devel] Re: PLT code and Mach-O, Camm Maguire, 2004/03/12
- RE: [Gcl-devel] Re: PLT code and Mach-O, Mike Thomas, 2004/03/14
- Re: [Gcl-devel] Re: PLT code and Mach-O, Camm Maguire, 2004/03/15
- Re: [Gcl-devel] Re: PLT code and Mach-O, Camm Maguire, 2004/03/16
Re: [Gcl-devel] PLT code and Mach-O, Camm Maguire, 2004/03/19
Re: [Gcl-devel] PLT code and Mach-O, Aurelien Chanudet, 2004/03/20
- [Gcl-devel] 2.6.2,
Camm Maguire <=