From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#10519: guile and (mini-)gmp Date: Mon, 16 Jan 2012 14:21:12 -0500 Message-ID: <871uqz313r.fsf@netris.org> References: <87aa5o2bm2.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1326741742 11688 80.91.229.12 (16 Jan 2012 19:22:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 16 Jan 2012 19:22:22 +0000 (UTC) Cc: 10519@debbugs.gnu.org, Torbjorn Granlund To: nisse@lysator.liu.se (Niels =?UTF-8?Q?M=C3=B6ller?=) Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Jan 16 20:22:18 2012 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rms8D-0001iQ-3V for guile-bugs@m.gmane.org; Mon, 16 Jan 2012 20:22:13 +0100 Original-Received: from localhost ([::1]:55734 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rms8C-0003QI-Dq for guile-bugs@m.gmane.org; Mon, 16 Jan 2012 14:22:12 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rms89-0003Pr-0P for bug-guile@gnu.org; Mon, 16 Jan 2012 14:22:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rms86-0004zz-97 for bug-guile@gnu.org; Mon, 16 Jan 2012 14:22:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rms86-0004zv-3Q for bug-guile@gnu.org; Mon, 16 Jan 2012 14:22:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Rms8z-0006gk-H2 for bug-guile@gnu.org; Mon, 16 Jan 2012 14:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 16 Jan 2012 19:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10519 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 10519-submit@debbugs.gnu.org id=B10519.132674177125695 (code B ref 10519); Mon, 16 Jan 2012 19:23:01 +0000 Original-Received: (at 10519) by debbugs.gnu.org; 16 Jan 2012 19:22:51 +0000 Original-Received: from localhost ([127.0.0.1]:60622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rms8p-0006gN-9n for submit@debbugs.gnu.org; Mon, 16 Jan 2012 14:22:51 -0500 Original-Received: from world.peace.net ([96.39.62.75]:42807) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rms8m-0006gF-Ti for 10519@debbugs.gnu.org; Mon, 16 Jan 2012 14:22:50 -0500 Original-Received: from c-98-216-245-176.hsd1.ma.comcast.net ([98.216.245.176] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Rms7n-000122-G1; Mon, 16 Jan 2012 14:21:47 -0500 In-Reply-To: ("Niels \=\?utf-8\?Q\?M\?\= \=\?utf-8\?Q\?\=C3\=B6ller\=22's\?\= message of "Mon, 16 Jan 2012 15:06:48 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6048 Archived-At: nisse@lysator.liu.se (Niels M=C3=B6ller) writes: > Mark H Weaver 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=C3=B6ller) 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