Subject: Re: bug#10519: guile and (mini-)gmp

From: [email-masked] (Niels Möller)
Date: Mon, 16 Jan 2012 15:06:48 +0100

Mark H Weaver <[email-masked]> writes:

> Don't worry about this.  I have a patch set that (among other things)
> reimplements scm_i_big2dbl in a much more robust way, with proper
> rounding, and without using such low-level GMP accessors.  I posted this
> patch set to guile-devel on 7 Oct, "[PATCH] Improvements to exact
> rationals et al".  I will resubmit it soon.

Nice! I take it you mean
http://lists.gnu.org/archive/html/guile-devel/2011-10/msg00004.html?
Please let me know when you post a new revision. I'm not subscribed to
any guile lists.

> [email-masked] (Niels Möller) writes:

>> 4. mini-gmp has no mp_set_memory_functions.

> No, it's much worse than that.  If most of the memory being allocated
> are bignums, then GC might not be run until the heap is quite large.

Will that be a problem in the cases where mini-gmp is relevant? I
imagine bignums will usually be at most a dozen limbs, so the storage
for limbs should just be a small factor larger than the storage for the
mpz_t structs (which are allocated in scheme objects, I assume).

> It would be good if you could duplicate the `mp_set_memory_functions'
> interface in mini-gmp.

I'll consider doing that, then. Are there any alternatives? I guess it
should be possible (but maybe inconvenient) to examine the allocation
count of each constructed bignum object and inform the gc. I imagine the
bignum objects in guile are immutable once created?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.