bug-gmp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CLN, GMP inputs


From: Hans Aberg
Subject: Re: CLN, GMP inputs
Date: Sat, 5 May 2001 23:16:40 +0200

At 05:52 +1000 2001/05/06, Kevin Ryde wrote:
>> I'm not sure what you mean with the need for "upward binary compatibility":
>> Is that for use in DLL's? Otherwise, only the interface would matter.
>
>Any program (or library) should be able to just re-link to a new
>libgmp and continue to work.  That means types like mpz_t must remain
>the same size, and fields that get accessed in application code must
>remain the same size and offset.  Applications don't directly access
>fields, but references to _mp_size and _mp_d are made via mpz_sgn and
>mpz_odd_p, and there'll be more similar inlining in the future.
>
>> The question is how GMP best can support that; if one achieves the effects
>> within GMP or by building something on top, I think matters little.
>
>It's to be hoped gmp provides enough building blocks to do useful
>things efficiently.

I checked with the GHC (Glasgow Glorious Haskell Compiler) bugs list for
inputs on GMP. I will try to summarize the discussions with Marcin 'Qrczak'
Kowalczyk <address@hidden>:

GHC heavily abuses the GMP interface, to the point that even if GMP changes
some functions to macros, GHC must be rewritten. GHC uses bit small number
(unboxed, without a pointer) representations, and big number (boxed, with a
pointer), in its own internal format.

GHC also provides the GMP version it uses with a special allocation
function that reserves space for the extra large number data, pretty much
as I suggested, and that you mentioned other versions of.

Then, as GHC determines that there is a small number overflow, it produces
suitable GMP mpz's, calls the suitable GMP function, and then converts the
result back to GHC's internal format.

Marcin Kowalczyk said that the use of small number representations were
said to speed GHC up a lot. But he cold not tell if it was due to merely
the accessing of GMP or due to the dynamic memory allocations. (My own
guess is that if GHC is using say a two-space copying conservative GC
(garbage collector), then memory allocations will be fast as long as they
do not hit GC time; but when GC time is included, the average memory
allocation time will not so short anymore.)

Also, the GHC code was written a long time ago.

If GMP would add small number representations, that might even be a
complication, because GHC might still need to convert to its internal
format. So if GMP would add small number representation, it should be easy
to detect which form it is from the outside. Also, I think that there must
be a format such an int, not an unsigned int plus a sign, in the small
number format.

So there are two conflicting conclusions one can make: Either keep GMP as
with as conservative changes as possible in order to not break the code of
others. But on the other hand, as it will not help anyhow, one might try to
give GMP new, better interface, and make a rather radical rewrite. But then
one must know a great deal how to proceed even before starting.

Perhaps one should keep GMP as close as it is today, and parallelly
introduce some new types with a more radical interface. At some point, one
can abandon the support of the old GMP in favor of the new version.

  Hans Aberg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]