From: Mark H Weaver <mhw@netris.org>
To: nisse@lysator.liu.se (Niels Möller)
Cc: 10519@debbugs.gnu.org, Torbjorn Granlund <tg@gmplib.org>
Subject: bug#10519: guile and (mini-)gmp
Date: Mon, 16 Jan 2012 14:21:12 -0500 [thread overview]
Message-ID: <871uqz313r.fsf@netris.org> (raw)
In-Reply-To: <nnaa5nyc5j.fsf@stalhein.lysator.liu.se> ("Niels \=\?utf-8\?Q\?M\?\= \=\?utf-8\?Q\?\=C3\=B6ller\=22's\?\= message of "Mon, 16 Jan 2012 15:06:48 +0100")
nisse@lysator.liu.se (Niels Möller) writes:
> Mark H Weaver <mhw@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@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
next prev parent reply other threads:[~2012-01-16 19:21 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-15 21:22 bug#10519: guile and (mini-)gmp Niels Möller
2012-01-16 10:19 ` Mark H Weaver
2012-01-16 14:06 ` Niels Möller
2012-01-16 19:21 ` Mark H Weaver [this message]
2012-01-28 9:49 ` Niels Möller
2012-01-28 10:10 ` Mark H Weaver
2012-07-22 9:04 ` Ludovic Courtès
2012-02-03 13:40 ` Andy Wingo
2012-02-03 19:56 ` Niels Möller
2012-02-03 20:01 ` Torbjorn Granlund
2012-02-04 22:46 ` Ludovic Courtès
2012-07-22 9:00 ` Ludovic Courtès
2012-07-22 23:17 ` Niels Möller
2012-08-10 21:51 ` Ludovic Courtès
2012-08-11 9:37 ` Niels Möller
2012-08-11 19:46 ` Ludovic Courtès
2012-08-11 21:50 ` Niels Möller
2012-08-11 22:48 ` Ludovic Courtès
2013-03-02 20:04 ` Andy Wingo
2013-03-02 20:58 ` Mark H Weaver
2013-03-05 19:09 ` Mark H Weaver
2013-03-18 0:01 ` Mark H Weaver
2013-03-18 9:19 ` Ludovic Courtès
2013-03-26 8:17 ` Niels Möller
2013-03-27 17:00 ` Mark H Weaver
2016-10-27 12:29 ` Niels Möller
2016-11-10 19:56 ` Andy Wingo
2013-03-02 21:45 ` Niels Möller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871uqz313r.fsf@netris.org \
--to=mhw@netris.org \
--cc=10519@debbugs.gnu.org \
--cc=nisse@lysator.liu.se \
--cc=tg@gmplib.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).