[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: large primes
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: large primes |
Date: |
03 Jun 2005 01:16:40 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
OK, 2.6.6twc+ is being compiled now at your site. Quite a lot of
changes -- should fix all the issues you've brought to my attention
recently, and passes all the usual tests, though I'd be stunned if I
haven't overlooked something. A summary of the changes, soo to go
into CVS head:
=============================================================================
1. pagesize defaults kept in configure, which also deduces the C stack
direction, alignment and upper bound, while taking new options to
disable the immediate fixnum table above the stack, and to set the c
stack size. configure should also lower DBEGIN to 0 automatically if
possible, giving you 128M more heap, and detect the shared library
ceiling if any. If maxpages goes beyond the ceiling, or the cstack
grows into maxpages, the sizes are adjusted automatically.
2. the holesize is a fraction of the core size, not of maxpages. this
may give a little more gc time, but addressed the concerns of some
that gcl allocates such a big chunk right off the bat. Of course,
this is settable.
3. The default stack alignment is restored, and attempts to
selectively wipe the holes have at least for now been replaced by a
strategy which simply pushes the C stack mark origin to the stack
pointer value right above TOP-LEVEL (making sure the C code above
this is safe). This pretty much ensures that
all memory can be collected from a top level gc.
4. automatic immediate fixnum table detection and setup. 512M
immediate fixnums on default Linux. I think you'll be pleased
comparing your mm benchmark with the ther lisps.
si::allocate-bigger-fixnum-range in acl2 should be made obsolete
(even counter productive) with this.
5. gmp random numbers. Worked around a gmp bug with small bases by
never calling with less than most-positive-fixnum, and scaling
afterward if necessary. Somewhat less efficient. Also need to
change the #$ reader to accept bignum seeds. (The number of the
random state is effectively the seed -- more on how to get this
from /dev/random later.)
6. C stack overrun detection and continuation code courtesy of
sigaltstack. Try GC'ing your very deep cons tree, or compile the
following and run (defun foo (x & optional y) (foo x y))
7. attempt to make the two word cons stuff endian and word size
independent. Still need to determine whether we want the even
word ad on 64bit for the other struct types.
8. use the symbol pad to store its hash value, hopefully accelerating
sxhash, hash-equal, etc. Also did a little tuning if ihash_equal.
9. opt_maxpage does not increase the maxpages beyond that would fit in
MAXPAGES if all types were fully allocated. opt_maxage called at
each GC to ensure statistics are collected even with the
setjmp/longjmp strategy of gmp_wrappers. Relocatable block
statistics are not collected for hole overruns. Worked on the
algorithm for new page allocateions in alloc_relblock. All these
algorithms in alloc.c desperately need cleaning and simplifying.
Also still need to come up with a mechanism to go into the debugger
break loop when storage is exhausted (as opposed to infinite
looping GC trying to allocate the space to print the message, etc.)
10. More info in (room)
11. GC cleans the C stack after itself.
12. GC support to gmp random numbers. Close GC cc_turbo mark
bug. ia64 support for second stack marking following primary stack
marking changes.
13. fixnum_times acceleration, acceleration for (expt 2 integer).
Printing your big prime overflows the c stack, but is now caught.
Could dynamically add more C stack in most situations at some
point.
Oh well, looking at the build, it appears that someone has removed the
headrs GCL needs from /lusr/include. Sigh -- this worked just a few
days ag. Will try to look into this when time arises.
Take care,
Robert Boyer <address@hidden> writes:
> According to one place on the web
> (http://primes.utm.edu/primes/search.php?Number=100) the largest known
> prime is:
>
> (- (expt 2 25964951) 1)
>
> GCL can compute this (in a rather long 7 seconds), but then causes a
> segmentation fault trying to print it.
>
> Bob and Warren
>
> -------------------------------------------------------------------------------
> Transcript
>
> % /p/bin/gcl
> GCL (GNU Common Lisp) 2.6.6 CLtL1 Jan 19 2005 20:24:14
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
>
> >(time (setq foo (- (expt 2 25964951) 1) bar nil))
>
> real time : 8.620 secs
> run-gbc time : 8.310 secs
> child run time : 0.000 secs
> gbc time : 0.060 secs
> NIL
>
> >foo
>
> Segmentation fault
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] Re: large primes,
Camm Maguire <=