[Gcl-devel] Re: 2.6.6twc+

[Camm Maguire]

Greetings!  OK, this is good news.

I'd like your opinion on whether you see any possible disadvantages
with these changes to generic gcl users.  My understanding of the
gctime increase is that it arises solely from the smaller holesize,
causing more gc calls, but that the overhead of any single gc has not
been significantly increased through the extra logic needed to handle
two word conses and immediate fixnums.  Confirmation of this if
possible would be great.  (In stock 2.6.6, the hole was MAXPAGE/10 at
all times, now it grows as a specified fraction of the current core
size, which seems more sensible for low memory users.  If you feel
this consideration is misguided, I'd like to hear about that too.)

I'm a little puzzled that the acl2 tests have not seen any gain from
the fixnum enhancements, but perhaps everything is already optimized
with fixnum declarations, etc.  At some point I'll run a profile on it
to see where the bottlenecks remain.  (If you happen to do this
anyway, please feel free to pass it along.)

I also hope you feel the fixnum table placement conforms with your
earlier advice to 'avoid heap restriction in any way'.  My
understanding is that one may be able to move the shared lib start and
the heap ceiling that arises therefrom, but that there is no way to
move the C stack start, so area above this value (in the case of
downcounting stack) is fair game.  Of course, if one could move the C
stack start to -1, then they way configure should work is to disable
the imm fixnum table and proceed without one.  I've actually tested a
version without the old SMALL_FIXNUM_TABLE nor the newer immfixnum
table, and everything appears to work.  The user can also dissable
this table at configuration time.  There are so many possible
combinations here that everything might not get completely tested, but
if the default is deemed non-restrictive, then I think we're OK.

Assuming the above issues are moot, then I take it from the below that
there are effectively no more gains to be had from integer arithmetic
nor random numbers.  If you find such examples, please forward them to
me while this stuff is fresh in my brain -- otherwise it appears best
to move to other items on the list.

Take care,

Robert Boyer <address@hidden> writes:

> Excellent testing news on 2.6.6twc+.  Finished all nqthm-1992, pc-nqthm-1992,
> and acl2 tests -- no problems.
> 
> Loading the test file rsa_examples.lisp (from http://examples.franz.com)
> takes 30 seconds in gcl-twc+ but 75 seconds under Allegro (both with
> (proclaim '(optimize (speed 3)))).  This is a serious exercise of the new GCL
> RANDOM function (mainly exercising bignum randoms) and of GCL's bignum
> arithmetic.  The GMP random number seems much, much better than the older GCL
> RANDOM.  Thanks!
> 
> (rsa::make-new-keys 200 206 "foo") takes about 10 seconds under 2.6.6twc+ and
> about 41 under Allegro.
> 
> twc+ seems about the same speed as 2.6.6 on the nqthm examples.
> 
>    2.6.6
>     run-gbc time    :   2117.740 secs
>     child run time  :    144.790 secs
>     gbc time        :    102.050 secs
>    2.6.6twc+
>     run-gbc time    :   2143.440 secs
>     child run time  :    157.520 secs
>     gbc time        :    160.010 secs
> 
> GCL only takes about 63 seconds to generate the p, q, d, and e, and for 400
> digit bit RSA.  (rsa::make-new-keys 400 406 "foo").  Amazing!  Allegro here
> gets a "This integer is too large to be converted to a double-float" error.
> 
>    "a 400-digit number would require a mere 8.6 * (10^15) years to factor. 
> This
>    is probably long enough; according to Stephen Hawking's A Brief History of
>    Time, the universe itself is only about 2 * (10^10) years old."
>     --   http://www.unix.org.ua/orelly/networking/puis/ch06_04.htm
> 
> For undeclared matrix multiply, twc+ takes 2.6 seconds, Allegro takes 4.7
> seconds, and gcl-2.6.6 takes 7.3 seconds.  So I think you have sped up GCL
> fixnum arithmetic by a factor of about 2.8.  Fantastic.  (This for
> multiplying two 300 by 300 matrices with random entries less than 1000 and no
> declarations at all.  Text for this below.)
> 
> What great work you do!
> 
> Bob
> 
> 
> -------------------------------------------------------------------------------
> 
> 
> The file mm.init
> 
> (eval-when (load compile eval) (proclaim '(optimize (speed 3))))
> 
> ; very dumb way to multiply two square matrices *a* and *b* and
> ; put the results in *c*.  *l* is the size of one dimension of the
> ; arrays.
> ; Call (m-init) to start.  Then (time (m-mm)) to see the cost of
> ; an array multiplication.
> 
> ; also maybe try (si::allocate-bigger-fixnum-range 0 20000000)
> 
> (defparameter *l*  300) ; dimension of array
> 
> (defparameter *x* 1000) ; maximum value for entries in a and b
> 
> (defvar *a*)
> (defvar *b*)
> (defvar *c*)
> 
> (defun m-init ()
>   (setq *a* (make-array (list *l* *l*)))
>   (setq *b* (make-array (list *l* *l*)))
>   (setq *c* (make-array (list *l* *l*)))
>   (loop for i below *l* do
>         (loop for j below *l* do
>               (setf (aref *a* i j) (random *x*))
>               (setf (aref *b* i j) (random *x*)))))
> 
> ; The purpose here is to test undeclared array and integer stuff!
> 
> (defun m-mm ()
>   (loop for i below *l* do
>         (loop for j below *l* do
>               (setf (aref *c* i j)
>                     (loop for k below *l* sum (* (aref *a* i k)
>                                                  (aref *b* k j)))))))
> 
> 
> 

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