ni...@lysator.liu.se (Niels Möller) writes:
> Mark H Weaver <m...@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.
>> ni...@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
