GNU bug report logs - #10519
guile and (mini-)gmp

Previous Next

Full log

Message #14 received at 10519 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: nisse <at> lysator.liu.se (Niels Möller)
Cc: 10519 <at> debbugs.gnu.org, Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Mon, 16 Jan 2012 14:21:12 -0500

nisse <at> lysator.liu.se (Niels Möller) writes:

> Mark H Weaver <mhw <at> netris.org> 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.

Yes, that's the message, and I'll make sure to keep you posted.

>> nisse <at> lysator.liu.se (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).

Even a relatively small factor can still be a problem.  Now that our VM
allows many programs to run without any evaluation-related allocation,
it's easily possible for bignums to be almost 100% of total allocations.
Suppose the ratio of limbs to mpz_t structs is N.  Then the heap will
grow to (N + 1) times the normal size before triggering GC.

Also, just because mini-gmp isn't recommended for very large numbers
doesn't mean that it won't occasionally be used for large numbers.  For
example, mini-gmp would probably do a reasonable job incrementing huge
numbers.  All it takes is a single huge counter that gets incremented
repeatedly to allocate a large amount of memory that GC doesn't know
about, and thus the heap can blow up even if only one or two of these
bignums would survive the next GC.

>> 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.

We could do as you suggest, but this is what scm_malloc and scm_realloc
are meant to do.  Why not provide a way for mini-gmp to use them?  In
general, being able to control how limbs are allocated seems important
in any system that includes GC'd bignums.

> I imagine the bignum objects in guile are immutable once created?

Yes.

    Thanks,
      Mark

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.