[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


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

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
> >foo
> Segmentation fault

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]