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.
("*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.
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. Cheers, Simon
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.
participants (2)
-
Remi Turk -
Simon Marlow