Re: bug

[Kevin Ryde]

Bill Schelter <address@hidden> writes:
> 
> I am incorporating gmp into GCL (gnu common lisp) to use
> with Maxima (free computer algebra system)
> http://www.ma.utexas.edu/maxima.html
> It gives MUCH better performance for bignums than the old pari
> code which I had used before.

Beaut.

> bug/comment 1):
> Unfortunately I will not be able to count on distributed libraries
> with various Linux distributions, since sometimes they are compiled
> on things like a K6, and that exits on an illegal instruction when
> I use things like mpz_popcount.

That's a fault in their packaging.  If they want something that runs
on i386 then it must be configured for i386.

> There ought to be a run time flag somewhere in the library, that
> gets set at first initting, that chooses the right code.  Almost all
> software we have has such run time checking OR no specific K6/K7
> code.

We prefer making the choice at configure time, since it keeps the code
size down and lets us ask gcc for cpu-specific optimizations in all
the C code as well as the asm code.  I guess gmp is a bit unusual in
trying, by default, to generate the best code it can for the system
it's built for.

> It is a real pain on networks with hundreds of machines to have to
> have two versions.

The lowest common denominator needs to be selected.  Maybe that needs
to be emphasised somewhere.


> bug 2) I found there is a bug in mpz_sizeinbase (compiled with gcc 2.95.2
> gmp 3.1.1).   It gives some bogus very large number in some cases.
> I think this may arise since 
>   count_leading_zeros (cnt, x->_mp_d[size - 1]);
> is called and in the case in question x->_mp_d[size - 1]
> is 0.  Indeed there are about 5 extra trailing 0's.   I am not
> sure why that is.   I just computed factorial 10000, so the
> bug may somehow be in the multiplying routines.    Dont know.  
> 
> (gdb) p *x
> $4 = {_mp_alloc = 3702, _mp_size = 3701, _mp_d = 0x834b05c}
> (gdb) p x->address@hidden
> $5 = {227330331, 574010, 0, 0, 0, 0, 0, 0, 0, 0}

Any time _mp_size is non-zero, the most significant limb of the mpz
must be non-zero.  If not then something has gone wrong somehow in a
preceding function.

> I believe the bug related to the count_leading_zeros and the zeroes
> in the product relates to my allocation/gc ...
> 
> I will try to straighten that out.   I see where the problem is.
> I thought you were using alloca internally for space, but you are
> sometimes using the other storage functions, which can cause a gc..

Yes the memory functions can be used for temporary space.  gmp always
frees what it allocates, so maybe memory handed to it doesn't need to
participate in gc.


> Each time a bignum is produced, there is a new call to init a new
> bignum.   Not very good to do I know but without doing some special
> compiler hacks to detect unaliased variables in lisp, i cant really
> do better.

I guess the same applies to any `big' object used arithmetically.