GHCI/FFI/GMP/Me madness
Remi Turk
buran at xs4all.nl
Fri Aug 13 09:03:32 EDT 2004
On Thu, Aug 12, 2004 at 09:30:58AM +0100, Simon Marlow wrote:
> On 11 August 2004 20:45, Remi Turk wrote:
>
> > But as long as GMP doesn't mind about being abused the way my
> > most recent util.c does, I can get away with the
> > mp_set_memory_functions-trick, can't I?
>
> Not really. You can't let GMP realloc() a memory block that was
> allocated using one method, with a different method. Also, GMP must not
> try to free() a block that was allocated using a different method.
I know, but my (latest) util.c doesn't do that. Every GMP-operation
is enclosed in two mp_set_memory_functions-calls.
> > ("*Be sure to call `mp_set_memory_functions' only when there are no
> > active GMP objects allocated using the previous memory functions!
> > Usually that means calling it before any other GMP function.*",
> > and using undocumented features)
> >
> > And with this trick and a ffi GMP-binding implement a working Mpz
> > datatype.
> >
> > And when (if?) this is done, drop in a "type Mpz = Integer", rip
> > out all Integer-primops, remove the mp_set_memory_functions-trick
> > and start benchmarking?
> > (Conveniently forgetting that "fromInteger :: Integer -> Integer"
> > most certainly has to stay a primop anyway...)
>
> How do you arrange to free a GMP integer when it is no longer referenced
> from the heap? You'd need finalizers, and that way lies madness. The
> memory allocation tricks we play with GMP are all to support GC of
> Integers.
Errr, I guess I'll have to start looking for a straitjacket then ;)
Finalisers where exactly what I was thinking about, and though
below implementation without doubt contains a bunch of bugs,
perhaps even show-stoppers, the following code _does_ print True:
import Mpz
main= print $ show (z::Integer) == show (z::Mpz)
where
-- some random calculations
x, y, z :: Blub a => a
x = 2^64 - sum (take 100 $ iterate (63*) 3)
y = 3^200 * 234233432 - (34 `pow` 38) + sum [1,87..20000]
z = fac 5000 * (x + y) `div` (2^100)
Or are finalisers simply going to be too slow to take seriously
for this?
> > Or is the rts using Integers in such a way that any (standard
> > malloc) allocations are forbidden while e.g. "(*) :: Integer ->
> > Integer -> Integer" is running?
> Not sure what you mean here - malloc() can always be used.
Never mind. You answered my question anyway ;)
Greetings,
Remi
--
Nobody can be exactly like me. Even I have trouble doing it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mpz.tar.gz
Type: application/x-tar-gz
Size: 3651 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/glasgow-haskell-users/attachments/20040813/e5d91537/Mpz.tar.bin
More information about the Glasgow-haskell-users
mailing list