* bug#10519: guile and (mini-)gmp @ 2012-01-15 21:22 Niels Möller 2012-01-16 10:19 ` Mark H Weaver ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Niels Möller @ 2012-01-15 21:22 UTC (permalink / raw) To: 10519; +Cc: Torbjorn Granlund Hi, I'm hacking on something called "mini-gmp" (see http://gmplib.org:8000/mini-gmp/). This is inteded to be a small and simple implementation of a GMP subset, suitable for programs which needs bignums, but which don't use very large numbers or very high performance. (I aimed for mini-gmp.c to be smaller than gmp's configure.in; currently, mini-gmp.c is some 10% larger). In part, this work was triggered by a discussion on how guile's gmp dependency is causing problems for programs using guile as an extension language, but which don't have any particular bignum needs. And I think minimality in terms of both dependencies and size of "core guile" is pretty important for guile to be successful as an extension language. One way to use mini-gmp, which I think would be appropriate for guile, is to bundle mini-gmp with the guile sources, and use it as a fallback in case the real GMP is not available. To try that out, I'm working with a slightly patched guile: I copied mini-gmp.c and .h to the libguile directory. configure.ac: Don't fail if gmp is not present, instead just add mini-gmp.o to LIBOBJS. And add an option --disable-gmp, to always use the bundled mini-gmp. Other files: #include <gmp.h> only when HAVE_LIBGMP is defined, and fall back to including "mini-gmp.h" otherwise. I'm then compiling guile to see how far I get and solve the problems I find. **End of background** I'm now going to describe a few of the problems. 1. The header file libguile.h. As far as I understand, this is a public header file and it's use of <gmp.h> means that the public guile ABI depends on gmp. Since mini-gmp is not binary compatible, that probably makes it more or less impossible to *install* guile when built with mini-gmp. The remaining case is an applications which bundle guile for using it as an extension language. Wnen the real gmp is unavailable, they still need a libguile.h which somehow includes mini-gmp.h rather than gmp.h. One solution might be to not modify include directives, but instead have configure create some symlink gmp.h -> mini-gmp.h in the build directory (to make --disable-gmp work, that directory must come before system directories where the real gmp-h file may be installed). The same directory also must be in the include path when building the application wanting to use guile. 2. The next problem is maybe more a nuisance than a real problem. I'm looking at scm_i_big2dbl, in numbers.c. I notice this code doesn't currently use mpz_get_d (comment says that's because gmp-4.2 and earlier didn't do well-defined rounding). Next, mpz_get_d in current gmp rounds towards zero. guile wants rounding to nearest, and it arranges this by testing the next lower bit. Unfortunately, it can't use mpz_tstbit directly, since for negative values it needs the bit of the abolute value, not of the two's complement. The code instead uses mpz_getlimbn and GMP_NUMB_BITS. That's not an unreasonable way to do it, but it causes problems for me because mini-gmp.h doesn't declare GMP_NUMB_BITS (and can't do, without including <limits.h> for CHAR_BIT, which is somewhat undesirable in the interface definition header, or use autoconf, which I'd really like to avoid here. Maybe I have to bite the bullet and define these constants (in mini-gmp, the correct value for both GMP_LIMB_BITS and GMP_NUMB_BITS is CHAR_BIT * sizeof(unsigned long)). Testing the bit in the absolute value could be done as mpz_init (t); mpz_abs (t, SCM_I_BIG_MPZ(b)); ...mpz_tstbit(t, pos)... mpz_clear (t); but that's an unnecessary allocation and copy. Maybe gmp (and mini-gmp) should have a function mpz_tstbitabs (and similarly for other bitops) which ignore the sign? Or should there be some mpz_get_d-like function with configurable rounding (I imagine libmpfr interfaces could provide some inspiration)? 3. Occcasional use of mpq functions (do_divide, scm_inexact_to_exact), for conversion of fradctions to and from doubles. mini-gmp has no mpq-functions (and it shouldn't have), so these calls have to either be eliminated altogether, or be made conditional on HAVE_LIBGMP. For conversion double->fraction, mpq seems overkill: Just multiply by a power of two to make the number an integer, to construct a fraction p / 2^k, and then eliminate any common factors of two (if fractions are required to be in some canonical form). For fraction->double, I think the current code using mpq_get_d rounds towards zero rather than towards nearest, which might not be what's desired. To avoid using mpq, I think converting p/q to a double could be done as follows: Find k so that floor (2^k p / q) is precisely the right number of bits (i.e., if precicion is n bits, 2^{n-1} q <= 2^k p < 2^n p). Compute the 2^k p / q appropriately rounded, and convert to double. There may be some corner case when 2^k p / q to have one more bit when rounded (upward) than when truncated. 4. mini-gmp has no mp_set_memory_functions. If I understand the the conservative gc used with guile right, having mini-gmp always use plain malloc and free should not cause any errors, just a slight waste of memory in case some limbs happen to be valid pointers. Which should be a small problem since one shouldn't use mini-gmp if the numbers get large. In guile, the calls could then just be made conditional on HAVE_LIBGMP. I'd apppreciate comments both on mini-gmp in general, and on the proper solution of the above issues. I may be able to prepare a few patches to guile, if I know what's desired. Ah, and I can report one build problem: The debian package of libgc doesn't include any .pc file, so when run without arguments, guile's configure failed to detect the precense of this library, even though I had the -dev package with libraries and header files installed. I figured out I should rerun configure with BDW_GC_LIBS="-lgc" and BDW_GC_CFLAGS="", and then the configure test passed, but -lgc for some reason wasn't added where it should in the Makefiles. I had to edit the generated libguile/Makefile and add it to LIBS there to be able to link. Happy hacking, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 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 ` (2 more replies) 2012-02-03 13:40 ` Andy Wingo 2012-07-22 9:00 ` Ludovic Courtès 2 siblings, 3 replies; 28+ messages in thread From: Mark H Weaver @ 2012-01-16 10:19 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund Hi Niels, thanks for looking into this! nisse@lysator.liu.se (Niels Möller) writes: > 2. The next problem is maybe more a nuisance than a real problem. I'm > looking at scm_i_big2dbl, in numbers.c. > > I notice this code doesn't currently use mpz_get_d (comment says > that's because gmp-4.2 and earlier didn't do well-defined rounding). > > Next, mpz_get_d in current gmp rounds towards zero. guile wants > rounding to nearest, and it arranges this by testing the next lower > bit. Unfortunately, it can't use mpz_tstbit directly, since for > negative values it needs the bit of the abolute value, not of the > two's complement. The code instead uses mpz_getlimbn and > GMP_NUMB_BITS. > > That's not an unreasonable way to do it, but it causes problems for > me because mini-gmp.h doesn't declare GMP_NUMB_BITS (and can't do, 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. > 3. Occcasional use of mpq functions (do_divide, scm_inexact_to_exact), > for conversion of fradctions to and from doubles. mini-gmp has no > mpq-functions (and it shouldn't have), so these calls have to either > be eliminated altogether, or be made conditional on HAVE_LIBGMP. > > For conversion double->fraction, mpq seems overkill: Just multiply by > a power of two to make the number an integer, to construct a fraction > p / 2^k, and then eliminate any common factors of two (if fractions > are required to be in some canonical form). Agreed. I can easily reimplement this to avoid the mpq functions, and will do so. > For fraction->double, I think the current code using mpq_get_d rounds > towards zero rather than towards nearest, which might not be what's > desired. To avoid using mpq, I think converting p/q to a double could > be done as follows: The aforementioned patch set already eliminates this use of the mpq functions. > 4. mini-gmp has no mp_set_memory_functions. If I understand the the > conservative gc used with guile right, having mini-gmp always use > plain malloc and free should not cause any errors, just a slight > waste of memory in case some limbs happen to be valid pointers. 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. That's because the GC decides when to run based on the allocations that it knows about. A potentially large amount of bignum data may be allocated before the GC heap gets big enough to trigger a collection. It doesn't know about memory allocated with plain malloc. However, it _does_ now know about memory allocated with scm_malloc. It would be good if you could duplicate the `mp_set_memory_functions' interface in mini-gmp. Thanks, Mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-01-16 10:19 ` Mark H Weaver @ 2012-01-16 14:06 ` Niels Möller 2012-01-16 19:21 ` Mark H Weaver 2012-01-28 9:49 ` Niels Möller 2012-07-22 9:04 ` Ludovic Courtès 2 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2012-01-16 14:06 UTC (permalink / raw) To: Mark H Weaver; +Cc: 10519, Torbjorn Granlund 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. > 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). > 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-01-16 14:06 ` Niels Möller @ 2012-01-16 19:21 ` Mark H Weaver 0 siblings, 0 replies; 28+ messages in thread From: Mark H Weaver @ 2012-01-16 19:21 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-01-16 10:19 ` Mark H Weaver 2012-01-16 14:06 ` Niels Möller @ 2012-01-28 9:49 ` Niels Möller 2012-01-28 10:10 ` Mark H Weaver 2012-07-22 9:04 ` Ludovic Courtès 2 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2012-01-28 9:49 UTC (permalink / raw) To: Mark H Weaver; +Cc: 10519, Torbjorn Granlund Mark H Weaver <mhw@netris.org> writes: > It would be good if you could duplicate the `mp_set_memory_functions' > interface in mini-gmp. I'm looking into this. I found that the GMP interface has one awkward feature: The current allocation size must be passed as an argument to the free and realloc functions. See http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html Does guile make any use of these size arguments? I'm considering having mini-gmp *not* support this part of the allocation interface, and instead always pass zero, for the sake of simplicity. I imagine that the vast majority of users of the custom alloction interface ignore these argments anyway, and store allocation size for each block elsewhere, e.g., in some block header. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-01-28 9:49 ` Niels Möller @ 2012-01-28 10:10 ` Mark H Weaver 0 siblings, 0 replies; 28+ messages in thread From: Mark H Weaver @ 2012-01-28 10:10 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund nisse@lysator.liu.se (Niels Möller) writes: > Mark H Weaver <mhw@netris.org> writes: > >> It would be good if you could duplicate the `mp_set_memory_functions' >> interface in mini-gmp. > > I'm looking into this. I found that the GMP interface has one awkward > feature: The current allocation size must be passed as an argument to > the free and realloc functions. See > http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html > > Does guile make any use of these size arguments? I'm considering having > mini-gmp *not* support this part of the allocation interface, and > instead always pass zero, for the sake of simplicity. Guile ignores the size arguments to the free and realloc functions, and I don't anticipate ever needing them in any future version of Guile. Thanks, Mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-01-16 10:19 ` Mark H Weaver 2012-01-16 14:06 ` Niels Möller 2012-01-28 9:49 ` Niels Möller @ 2012-07-22 9:04 ` Ludovic Courtès 2 siblings, 0 replies; 28+ messages in thread From: Ludovic Courtès @ 2012-07-22 9:04 UTC (permalink / raw) To: Mark H Weaver; +Cc: 10519, Niels Möller, Torbjorn Granlund Hi Mark! Mark H Weaver <mhw@netris.org> skribis: > nisse@lysator.liu.se (Niels Möller) writes: >> 2. The next problem is maybe more a nuisance than a real problem. I'm >> looking at scm_i_big2dbl, in numbers.c. >> >> I notice this code doesn't currently use mpz_get_d (comment says >> that's because gmp-4.2 and earlier didn't do well-defined rounding). [...] > 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. Apparently this didn’t make it into the tree yet, right? Could you resubmit it? >> 3. Occcasional use of mpq functions (do_divide, scm_inexact_to_exact), >> for conversion of fradctions to and from doubles. mini-gmp has no >> mpq-functions (and it shouldn't have), so these calls have to either >> be eliminated altogether, or be made conditional on HAVE_LIBGMP. >> >> For conversion double->fraction, mpq seems overkill: Just multiply by >> a power of two to make the number an integer, to construct a fraction >> p / 2^k, and then eliminate any common factors of two (if fractions >> are required to be in some canonical form). > > Agreed. I can easily reimplement this to avoid the mpq functions, and > will do so. Nice. Could you look into it? :-) Thanks! Ludo’. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-01-15 21:22 bug#10519: guile and (mini-)gmp Niels Möller 2012-01-16 10:19 ` Mark H Weaver @ 2012-02-03 13:40 ` Andy Wingo 2012-02-03 19:56 ` Niels Möller 2012-07-22 9:00 ` Ludovic Courtès 2 siblings, 1 reply; 28+ messages in thread From: Andy Wingo @ 2012-02-03 13:40 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund, Mark H. Weaver Greets, Thanks for working on this, Niels, and thanks for following up on it, Mark. It's great to have such knowledgeable folk working on this problem. One suggestion, if it's possible: it would be great if mini-gmp could make it to be part of gnulib at some point. That's probably the easiest way of providing this functionality to all GNU programs, in a way that allows changes to mini-gmp to propagate to their users (via the gnulib update mechanism). Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-02-03 13:40 ` Andy Wingo @ 2012-02-03 19:56 ` Niels Möller 2012-02-03 20:01 ` Torbjorn Granlund 0 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2012-02-03 19:56 UTC (permalink / raw) To: Andy Wingo; +Cc: 10519, Torbjorn Granlund, Mark H. Weaver Andy Wingo <wingo@pobox.com> writes: > One suggestion, if it's possible: it would be great if mini-gmp could > make it to be part of gnulib at some point. It's main home will be the GMP repo and distributions. But that doesn't exclude that it's also copied into gnulib, if that's convenient. BTW, I added the mp_{get,set}_memory_functions a few days ago. Not exercised by any tests, though. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-02-03 19:56 ` Niels Möller @ 2012-02-03 20:01 ` Torbjorn Granlund 2012-02-04 22:46 ` Ludovic Courtès 0 siblings, 1 reply; 28+ messages in thread From: Torbjorn Granlund @ 2012-02-03 20:01 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Mark H. Weaver nisse@lysator.liu.se (Niels Möller) writes: Andy Wingo <wingo@pobox.com> writes: > One suggestion, if it's possible: it would be great if mini-gmp could > make it to be part of gnulib at some point. It's main home will be the GMP repo and distributions. But that doesn't exclude that it's also copied into gnulib, if that's convenient. We should make a VERY clear note in the file about the home position, and that the file should better not be extended and put into gnulib, to avoid incompatibility between two version. This is not about being in control, but about avoiding to confuse users with incompatible mini-gmp.c variants. -- Torbjörn ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-02-03 20:01 ` Torbjorn Granlund @ 2012-02-04 22:46 ` Ludovic Courtès 0 siblings, 0 replies; 28+ messages in thread From: Ludovic Courtès @ 2012-02-04 22:46 UTC (permalink / raw) To: 10519 Hello, Torbjorn Granlund <tg@gmplib.org> skribis: > nisse@lysator.liu.se (Niels Möller) writes: > > Andy Wingo <wingo@pobox.com> writes: > > > One suggestion, if it's possible: it would be great if mini-gmp could > > make it to be part of gnulib at some point. > > It's main home will be the GMP repo and distributions. But that doesn't > exclude that it's also copied into gnulib, if that's convenient. > > We should make a VERY clear note in the file about the home position, > and that the file should better not be extended and put into gnulib, to > avoid incompatibility between two version. Gnulib has bits from libc, for example, and in that case the module file has “libc” in its “Maintainer” field. So I guess the maintainer of the mini-gmp module could be “gmp”. Thanks, Ludo.’ ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-01-15 21:22 bug#10519: guile and (mini-)gmp Niels Möller 2012-01-16 10:19 ` Mark H Weaver 2012-02-03 13:40 ` Andy Wingo @ 2012-07-22 9:00 ` Ludovic Courtès 2012-07-22 23:17 ` Niels Möller 2 siblings, 1 reply; 28+ messages in thread From: Ludovic Courtès @ 2012-07-22 9:00 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund Hello! Reviving the discussion, as we’ve been discussing this at the GHM, and some people would really like to see it happen. :-) nisse@lysator.liu.se (Niels Möller) skribis: > To try that out, I'm working with a slightly patched guile: Do you still have the patch around? > 1. The header file libguile.h. As far as I understand, this is a public > header file and it's use of <gmp.h> means that the public guile ABI > depends on gmp. The problem is that there’s a public API dealing with mpz_t: SCM_API void scm_to_mpz (SCM x, mpz_t rop); SCM_API SCM scm_from_mpz (mpz_t rop); So, when mini-gmp is used, a <gmp.h> header should be installed as well, say under <libguile/mini-gmp.h>. WDYT? > Since mini-gmp is not binary compatible, I don’t think there’s a problem, because only mpz_t objects appear in the API, and they’re pointers. > 4. mini-gmp has no mp_set_memory_functions. So apparently you eventually added them, thanks! Thanks, Ludo’. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-07-22 9:00 ` Ludovic Courtès @ 2012-07-22 23:17 ` Niels Möller 2012-08-10 21:51 ` Ludovic Courtès 0 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2012-07-22 23:17 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 10519, Torbjorn Granlund [-- Attachment #1: Type: text/plain, Size: 2951 bytes --] ludo@gnu.org (Ludovic Courtès) writes: > Reviving the discussion, as we’ve been discussing this at the GHM, and > some people would really like to see it happen. :-) Great! Any summary of the discussion, for those of us who couldn't make it there? > nisse@lysator.liu.se (Niels Möller) skribis: > >> To try that out, I'm working with a slightly patched guile: > > Do you still have the patch around? I'm attaching a patch from I tree I have around, without reading it carefully. I'm not sure this is the latest version I worked with. Maybe it's of some use. >> 1. The header file libguile.h. As far as I understand, this is a public >> header file and it's use of <gmp.h> means that the public guile ABI >> depends on gmp. > > The problem is that there’s a public API dealing with mpz_t: Exactly. To me, that seems like a potentially hairy problem to get right. > SCM_API void scm_to_mpz (SCM x, mpz_t rop); > SCM_API SCM scm_from_mpz (mpz_t rop); > > So, when mini-gmp is used, a <gmp.h> header should be installed as well, > say under <libguile/mini-gmp.h>. WDYT? Maybe it would make sense with a level of indirection. User's could include libguile/bignum.h, which would in turn include either mini-gmp.h or the real gmp.h, depending on how guile was configured. Users may also need some way of figuring out if they need to link with -lgmp or not. >> Since mini-gmp is not binary compatible, > > I don’t think there’s a problem, because only mpz_t objects appear in > the API, and they’re pointers. mpz_t is a typedef, which is a single element array of a semi-internal struct. So when you declare mpz_t x; you are really declaring a struct, not a pointer (and then the array type automatically "decays" to a pointer when passed as a function argument). But it's likely that mini-gmp will use the same size of that struct. And even the same layout. I think the main ABI incompatibilities are that 1. symbol names, as seen by the linker, are different. With gmp, mpz_foo is a name mangling #define, and the real name is ___gmpz_foo. mini-gmp doesn't do that. 2. mp_limb_t may be of different size: With mini-gmp, it's always unsigned long, with gmp it's unsigned long long on some platforms (notably 64-bit windows, I think). Hmm, or if you're saying that the use of mpz_t in guile's public API is pointers only, that that might make things a little simpler. But things will still break badly if the user's code is linked with gmp and guile uses mini-gmp, or vice versa. >> 4. mini-gmp has no mp_set_memory_functions. That's added now, with the subtle difference that mini-gmp doesn't pass a valid size for the old_size argument for the free and realloc functions. I don't think guile depends on that feature. Please also note that the most recent version of mini-gmp is now the one included in the main gmp repo. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: guile-mini-gmp.patch --] [-- Type: text/x-patch, Size: 3254 bytes --] diff --git a/configure.ac b/configure.ac index a32ff4b..089dfbe 100644 --- a/configure.ac +++ b/configure.ac @@ -146,6 +146,10 @@ AC_ARG_ENABLE(regex, [ --disable-regex omit regular expression interfaces],, enable_regex=yes) +AC_ARG_ENABLE(gmp, + [ --disable-gmp omit high performance bignums],, + enable_gmp=yes) + AC_ARG_ENABLE([deprecated], AS_HELP_STRING([--disable-deprecated],[omit deprecated features])) @@ -869,15 +873,20 @@ fi AC_CACHE_SAVE dnl GMP tests +if test "x$enable_gmp" != xno ; then AC_LIB_HAVE_LINKFLAGS([gmp], [], [#include <gmp.h>], [mpz_import (0, 0, 0, 0, 0, 0, 0);]) if test "x$HAVE_LIBGMP" != "xyes"; then - AC_MSG_ERROR([GNU MP 4.1 or greater not found, see README]) + AC_MSG_NOTICE([GNU MP 4.1 or greater not found, see README]) + enable_gmp=no +fi +fi +if test "x$enable_gmp" = xno ; then + AC_LIBOBJ([mini-gmp]) fi - dnl GNU libunistring is checked for by Gnulib's `libunistring' module. if test "x$LTLIBUNISTRING" = "x"; then AC_MSG_ERROR([GNU libunistring is required, please install it.]) @@ -1253,7 +1262,7 @@ main (int argc, char **argv) # Boehm's GC library # #-------------------------------------------------------------------- -PKG_CHECK_MODULES([BDW_GC], [bdw-gc]) +# PKG_CHECK_MODULES([BDW_GC], [bdw-gc]) save_LIBS="$LIBS" LIBS="$BDW_GC_LIBS $LIBS" diff --git a/libguile.h b/libguile.h index 7ac98a5..457dd66 100644 --- a/libguile.h +++ b/libguile.h @@ -22,8 +22,11 @@ /* This needs to be included outside of the extern "C" block. */ +#if HAVE_LIBGMP #include <gmp.h> - +#else +#include "libguile/mini-gmp.h" +#endif #ifdef __cplusplus extern "C" { #endif diff --git a/libguile/bytevectors.c b/libguile/bytevectors.c index 811e8d8..240e457 100644 --- a/libguile/bytevectors.c +++ b/libguile/bytevectors.c @@ -24,7 +24,11 @@ #include <alloca.h> #include <assert.h> +#if HAVE_LIBGMP #include <gmp.h> +#else +#include "mini-gmp.h" +#endif #include "libguile/_scm.h" #include "libguile/extensions.h" diff --git a/libguile/init.c b/libguile/init.c index 35ab856..bb79422 100644 --- a/libguile/init.c +++ b/libguile/init.c @@ -29,7 +29,11 @@ #include <stdio.h> #include <sys/stat.h> #include <fcntl.h> +#if HAVE_LIBGMP #include <gmp.h> +#else +#include "mini-gmp.h" +#endif #include "libguile/_scm.h" diff --git a/libguile/numbers.h b/libguile/numbers.h index b7bcfe4..166f222 100644 --- a/libguile/numbers.h +++ b/libguile/numbers.h @@ -22,9 +22,11 @@ */ \f - +#ifdef HAVE_LIBGMP #include <gmp.h> - +#else +#include "mini-gmp.h" +#endif #include "libguile/__scm.h" #include "libguile/print.h" diff --git a/libguile/random.c b/libguile/random.c index 8bc0d87..c216245 100644 --- a/libguile/random.c +++ b/libguile/random.c @@ -25,7 +25,11 @@ #include "libguile/_scm.h" +#if HAVE_LIBGMP #include <gmp.h> +#else +#include "mini-gmp.h" +#endif #include <stdio.h> #include <math.h> #include <string.h> diff --git a/libguile/socket.c b/libguile/socket.c index d085d33..5ec20a2 100644 --- a/libguile/socket.c +++ b/libguile/socket.c @@ -25,7 +25,11 @@ #endif #include <errno.h> +#if HAVE_LIBGMP #include <gmp.h> +#else +#include "mini-gmp.h" +#endif #include "libguile/_scm.h" #include "libguile/arrays.h" [-- Attachment #3: Type: text/plain, Size: 157 bytes --] Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply related [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-07-22 23:17 ` Niels Möller @ 2012-08-10 21:51 ` Ludovic Courtès 2012-08-11 9:37 ` Niels Möller 0 siblings, 1 reply; 28+ messages in thread From: Ludovic Courtès @ 2012-08-10 21:51 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund Hi Niels, nisse@lysator.liu.se (Niels Möller) skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> Reviving the discussion, as we’ve been discussing this at the GHM, and >> some people would really like to see it happen. :-) > > Great! Any summary of the discussion, for those of us who couldn't make > it there? Mostly a few people reaffirmed the need for this. > I'm attaching a patch from I tree I have around, without reading it > carefully. I'm not sure this is the latest version I worked with. Maybe > it's of some use. Yes, thanks. I just tried it, and here’s the status: - numbers.c uses ‘GMP_NUMB_BITS’, which is lacking; - it also still uses mpq’s, as Mark noted; - random.c uses ‘mpz_realloc2’, also lacking. >>> 1. The header file libguile.h. As far as I understand, this is a public >>> header file and it's use of <gmp.h> means that the public guile ABI >>> depends on gmp. >> >> The problem is that there’s a public API dealing with mpz_t: > > Exactly. To me, that seems like a potentially hairy problem to get > right. > >> SCM_API void scm_to_mpz (SCM x, mpz_t rop); >> SCM_API SCM scm_from_mpz (mpz_t rop); >> >> So, when mini-gmp is used, a <gmp.h> header should be installed as well, >> say under <libguile/mini-gmp.h>. WDYT? > > Maybe it would make sense with a level of indirection. User's could > include libguile/bignum.h, which would in turn include either mini-gmp.h > or the real gmp.h, depending on how guile was configured. Users are only supposed to include <libguile.h>; headers under libguile/ aren’t meant to be included directly. Currently including <libguile.h> pulls <gmp.h>. When mini-GMP is used instead, then <libguile/mini-gmp.h> would be pulled instead, transparently. > Users may also need some way of figuring out if they need to link with > -lgmp or not. libguile-2.0.la and guile-2.0.pc would provide that info. >>> Since mini-gmp is not binary compatible, >> >> I don’t think there’s a problem, because only mpz_t objects appear in >> the API, and they’re pointers. [...] > Hmm, or if you're saying that the use of mpz_t in guile's public API is > pointers only, that that might make things a little simpler. But things > will still break badly if the user's code is linked with gmp and guile > uses mini-gmp, or vice versa. Exactly, that’s the only case where it would break, AFAICS. And it’s probably an unlikely use case: users who want to use both GMP and Guile surely have libguile linked against GMP. >>> 4. mini-gmp has no mp_set_memory_functions. > > That's added now, with the subtle difference that mini-gmp doesn't pass > a valid size for the old_size argument for the free and realloc > functions. I don't think guile depends on that feature. No, it doesn’t. I’m slightly concerned about mini-gmp, though. It’s almost 5000 lines, mostly copied from GMP AIUI, but with no way to synchronize. How do you consider the maintenance cost of this? I understand some people want this, and I’m happy you’re helping, but the amount of work and duplication involved would definitely be a showstopper for me if you and Mark weren’t helping. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-08-10 21:51 ` Ludovic Courtès @ 2012-08-11 9:37 ` Niels Möller 2012-08-11 19:46 ` Ludovic Courtès 0 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2012-08-11 9:37 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 10519, Torbjorn Granlund ludo@gnu.org (Ludovic Courtès) writes: > Yes, thanks. I just tried it, and here’s the status: > > - numbers.c uses ‘GMP_NUMB_BITS’, which is lacking; If that's really needed, it can be substituted with something like #ifndef GMP_NUMB_BITS #include <limits.h> #define GMP_NUMB_BITS (CHAR_BIT*sizeof(mp_limb_t)) #endif I hesitate to add it to mini-gmp.h, unless I can find a way to define it without relying on limits.h or autoconf. > - it also still uses mpq’s, as Mark noted; This is being addressed, I hope. > - random.c uses ‘mpz_realloc2’, also lacking. That call could be conditional on HAVE_LIBGMP, I think. > Currently including <libguile.h> pulls <gmp.h>. When mini-GMP is used > instead, then <libguile/mini-gmp.h> would be pulled instead, > transparently. Might work. You'd need to document that a guile application which wants to work with mini-gmp should never include gmp.h directly. >> Users may also need some way of figuring out if they need to link with >> -lgmp or not. > > libguile-2.0.la and guile-2.0.pc would provide that info. And on ELF-systems, you should record the dependency (or lack thereof) directly in libguile.so. > I’m slightly concerned about mini-gmp, though. It’s almost 5000 lines, > mostly copied from GMP AIUI, but with no way to synchronize. How do you > consider the maintenance cost of this? My view is that you should copy mini-gmp from some gmp release or from the main gmp repo. When you have a version which works for you, you shouldn't need to modify it or update it very often (maybe once for each gmp release or so). And if you need to make any modifications, you ought to bug-report the corresponding problem. Hopefully, problems can be fixed in the gmp repo, so that guile can simply upgrade to the latest version from the gmp repo, rather than maintaining your own changes. The GMP developers have also considered adding #ifdef:ery in mini-gmp.c, to let the application specify precisely which features are wanted. (And I'm not sure what you mean with "GMP AIUI"). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-08-11 9:37 ` Niels Möller @ 2012-08-11 19:46 ` Ludovic Courtès 2012-08-11 21:50 ` Niels Möller 0 siblings, 1 reply; 28+ messages in thread From: Ludovic Courtès @ 2012-08-11 19:46 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund Hi, nisse@lysator.liu.se (Niels Möller) skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> Yes, thanks. I just tried it, and here’s the status: >> >> - numbers.c uses ‘GMP_NUMB_BITS’, which is lacking; > > If that's really needed, it can be substituted with something like > > #ifndef GMP_NUMB_BITS > #include <limits.h> > #define GMP_NUMB_BITS (CHAR_BIT*sizeof(mp_limb_t)) > #endif OK. [...] >> - random.c uses ‘mpz_realloc2’, also lacking. > > That call could be conditional on HAVE_LIBGMP, I think. Right. >> Currently including <libguile.h> pulls <gmp.h>. When mini-GMP is used >> instead, then <libguile/mini-gmp.h> would be pulled instead, >> transparently. > > Might work. You'd need to document that a guile application which wants > to work with mini-gmp should never include gmp.h directly. Yes. >>> Users may also need some way of figuring out if they need to link with >>> -lgmp or not. >> >> libguile-2.0.la and guile-2.0.pc would provide that info. > > And on ELF-systems, you should record the dependency (or lack thereof) > directly in libguile.so. Of course. >> I’m slightly concerned about mini-gmp, though. It’s almost 5000 lines, >> mostly copied from GMP AIUI, but with no way to synchronize. How do you >> consider the maintenance cost of this? > > My view is that you should copy mini-gmp from some gmp release or from > the main gmp repo. When you have a version which works for you, you > shouldn't need to modify it or update it very often (maybe once for each > gmp release or so). For me/us, the best workflow would be to have a Gnulib module. That way, whenever GMP developers fix a bug in mini-gmp, we automatically get the fix when running “gnulib-tool --update”. > And if you need to make any modifications, you ought to bug-report the > corresponding problem. Hopefully, problems can be fixed in the gmp repo, > so that guile can simply upgrade to the latest version from the gmp > repo, rather than maintaining your own changes. Sure. What about the maintenance overhead for GMP developers? I mean, of those 5000 lines, most are copied from GMP, right? So, bugs found in GMP may have to be fixed in mini-GMP too, for instance. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-08-11 19:46 ` Ludovic Courtès @ 2012-08-11 21:50 ` Niels Möller 2012-08-11 22:48 ` Ludovic Courtès 0 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2012-08-11 21:50 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 10519, Torbjorn Granlund ludo@gnu.org (Ludovic Courtès) writes: > For me/us, the best workflow would be to have a Gnulib module. That > way, whenever GMP developers fix a bug in mini-gmp, we automatically get > the fix when running “gnulib-tool --update”. I guess you can do whatever you want in gnulib. But it should be made very clear that the gmp repo is the "official" version. Some gmp developers would be upset if a mini-gmp version in gnulib starts to diverge. > What about the maintenance overhead for GMP developers? I mean, of > those 5000 lines, most are copied from GMP, right? Not really. Some of that code is of course copied from various other gmp files, but a lot of it is written from scratch, giving priority to simplicity over performance. > So, bugs found in GMP may have to be fixed in mini-GMP too, for > instance. That's possible, but I don't think it's likely to be a big problem. I'd expect the typical bug in mini-gmp to be in the code which is *not* copied from other GMP files. And I'd expect the typical bug in gmp to be in complex algorithms or assembly code, which doesn't have any counterpart in mini-gmp. mini-gmp does have a reasonable testsuite, even if it's not as thorough as the main gmp testsuite. And mini-gmp is used in a normal gmp build (via bootstrap.c), for computing various tables used by the main gmp code. So the gmp project itself also depends on mini-gmp. Reards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2012-08-11 21:50 ` Niels Möller @ 2012-08-11 22:48 ` Ludovic Courtès 2013-03-02 20:04 ` Andy Wingo 0 siblings, 1 reply; 28+ messages in thread From: Ludovic Courtès @ 2012-08-11 22:48 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Torbjorn Granlund nisse@lysator.liu.se (Niels Möller) skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> For me/us, the best workflow would be to have a Gnulib module. That >> way, whenever GMP developers fix a bug in mini-gmp, we automatically get >> the fix when running “gnulib-tool --update”. > > I guess you can do whatever you want in gnulib. But it should be made > very clear that the gmp repo is the "official" version. Some gmp > developers would be upset if a mini-gmp version in gnulib starts to > diverge. Yes, sure. There are cases where Gnulib contains copies of code actually maintained elsewhere, such as in glibc. I’ll check with the Gnulib folks whether/how such an arrangement could be made. >> What about the maintenance overhead for GMP developers? I mean, of >> those 5000 lines, most are copied from GMP, right? > > Not really. Some of that code is of course copied from various other gmp > files, but a lot of it is written from scratch, giving priority to > simplicity over performance. OK. >> So, bugs found in GMP may have to be fixed in mini-GMP too, for >> instance. > > That's possible, but I don't think it's likely to be a big problem. I'd > expect the typical bug in mini-gmp to be in the code which is *not* > copied from other GMP files. And I'd expect the typical bug in gmp to be > in complex algorithms or assembly code, which doesn't have any > counterpart in mini-gmp. Right. > mini-gmp does have a reasonable testsuite, even if it's not as thorough > as the main gmp testsuite. And mini-gmp is used in a normal gmp build > (via bootstrap.c), for computing various tables used by the main gmp > code. So the gmp project itself also depends on mini-gmp. OK, good to know. ;-) Thanks! Ludo’. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 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-02 21:45 ` Niels Möller 0 siblings, 2 replies; 28+ messages in thread From: Andy Wingo @ 2013-03-02 20:04 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 10519, Niels Möller, Torbjorn Granlund Hi, A ping on this bug on getting Guile to have the possibility of using an embedded copy of mini-gmp. 1. What is the status of mini-gmp? I understand that you use it in GMP itself, so hopefully mini-gmp is in a good state, upstream. 2. Has anyone looked at getting mini-gmp into Gnulib? We are working on another Guile release and if this feature is close to completion, it could make it into the release. Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 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-02 21:45 ` Niels Möller 1 sibling, 1 reply; 28+ messages in thread From: Mark H Weaver @ 2013-03-02 20:58 UTC (permalink / raw) To: Andy Wingo Cc: 10519, Ludovic Courtès, Niels Möller, Torbjorn Granlund Hi Andy, Andy Wingo <wingo@pobox.com> writes: > A ping on this bug on getting Guile to have the possibility of using an > embedded copy of mini-gmp. I'm embarrassed to admit that the integration of mini-gmp into guile has long been waiting on my pending numerics patches. I'll try to get going on this (and some other things) for the 2.0.8 release. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10519#8 Thanks, Mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2013-03-02 20:58 ` Mark H Weaver @ 2013-03-05 19:09 ` Mark H Weaver 2013-03-18 0:01 ` Mark H Weaver 0 siblings, 1 reply; 28+ messages in thread From: Mark H Weaver @ 2013-03-05 19:09 UTC (permalink / raw) To: Andy Wingo Cc: 10519, Ludovic Courtès, Niels Möller, Torbjorn Granlund Hello all, I wrote: > I'm embarrassed to admit that the integration of mini-gmp into guile has > long been waiting on my pending numerics patches. I'll try to get going > on this (and some other things) for the 2.0.8 release. > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10519#8 I've posted a new set of patches for stable-2.0 to guile-devel: http://lists.gnu.org/archive/html/guile-devel/2013-03/msg00011.html This patch set eliminates the known obstacles to integration of mini-gmp. Regards, Mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2013-03-05 19:09 ` Mark H Weaver @ 2013-03-18 0:01 ` Mark H Weaver 2013-03-18 9:19 ` Ludovic Courtès ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Mark H Weaver @ 2013-03-18 0:01 UTC (permalink / raw) To: Andy Wingo Cc: 10519, Ludovic Courtès, Niels Möller, Torbjorn Granlund FYI, I've pushed patches to Guile's git repository (stable-2.0 branch) which eliminate the known obstacles to mini-gmp integration. Mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2013-03-18 0:01 ` Mark H Weaver @ 2013-03-18 9:19 ` Ludovic Courtès 2013-03-26 8:17 ` Niels Möller 2016-10-27 12:29 ` Niels Möller 2 siblings, 0 replies; 28+ messages in thread From: Ludovic Courtès @ 2013-03-18 9:19 UTC (permalink / raw) To: Mark H Weaver; +Cc: 10519, Niels Möller, Torbjorn Granlund Mark H Weaver <mhw@netris.org> skribis: > FYI, I've pushed patches to Guile's git repository (stable-2.0 branch) > which eliminate the known obstacles to mini-gmp integration. Great, thanks! And sorry for not following more closely... Ludo’. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 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 2 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2013-03-26 8:17 UTC (permalink / raw) To: Mark H Weaver; +Cc: 10519, Ludovic Courtès, Torbjorn Granlund Mark H Weaver <mhw@netris.org> writes: > FYI, I've pushed patches to Guile's git repository (stable-2.0 branch) > which eliminate the known obstacles to mini-gmp integration. Out of curiosity, I had a quick look at the patches as posted to the guile devel list. For the small integer gcd code, you may want to have a look at the tricks used in http://gmplib.org:8000/gmp/file/304af17b9ccc/mpn/generic/gcd_1.c, the code under GCD_1_METHOD == 2 1. Shift out the least significant bit of both a and b (they're always one). Maybe you don't need this of you have some extra bits already (signed types, or some bits reserved for type info). 2. Then, the sign bit of a - b correctly gives the result of the comparison a < b. Constructing a mask from this difference is then a simple right shift (if >> on a signed int is not an arithmetic right shift, you need shift and a negation). 3. Use this bit mask when forming the absolute value |a - b|, and when swapping values around, to avoid unpredictable branches which typically are quite expensive. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2013-03-26 8:17 ` Niels Möller @ 2013-03-27 17:00 ` Mark H Weaver 0 siblings, 0 replies; 28+ messages in thread From: Mark H Weaver @ 2013-03-27 17:00 UTC (permalink / raw) To: Niels Möller; +Cc: 10519, Ludovic Courtès, Torbjorn Granlund Hi Niels, nisse@lysator.liu.se (Niels Möller) writes: > For the small integer gcd code, you may want to have a look at the > tricks used in > http://gmplib.org:8000/gmp/file/304af17b9ccc/mpn/generic/gcd_1.c, the > code under GCD_1_METHOD == 2 > > 1. Shift out the least significant bit of both a and b (they're always > one). Maybe you don't need this of you have some extra bits already > (signed types, or some bits reserved for type info). > > 2. Then, the sign bit of a - b correctly gives the result of the > comparison a < b. Constructing a mask from this difference is then a > simple right shift (if >> on a signed int is not an arithmetic right > shift, you need shift and a negation). > > 3. Use this bit mask when forming the absolute value |a - b|, and when > swapping values around, to avoid unpredictable branches which > typically are quite expensive. Excellent tricks! Thanks for sharing. I'll try to find the time to apply these ideas soon, but probably not before 2.0.8 -- there are too many more important things to do for that, and not enough time. Regards, Mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2013-03-18 0:01 ` Mark H Weaver 2013-03-18 9:19 ` Ludovic Courtès 2013-03-26 8:17 ` Niels Möller @ 2016-10-27 12:29 ` Niels Möller 2016-11-10 19:56 ` Andy Wingo 2 siblings, 1 reply; 28+ messages in thread From: Niels Möller @ 2016-10-27 12:29 UTC (permalink / raw) To: Mark H Weaver; +Cc: 10519, Ludovic Courtès, Torbjorn Granlund Mark H Weaver <mhw@netris.org> writes: > FYI, I've pushed patches to Guile's git repository (stable-2.0 branch) > which eliminate the known obstacles to mini-gmp integration. Hi, I'm curious if there's been any further progress? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2016-10-27 12:29 ` Niels Möller @ 2016-11-10 19:56 ` Andy Wingo 0 siblings, 0 replies; 28+ messages in thread From: Andy Wingo @ 2016-11-10 19:56 UTC (permalink / raw) To: Niels Möller; +Cc: Ludovic Courtès, Torbjorn Granlund, 10519 On Thu 27 Oct 2016 14:29, nisse@lysator.liu.se (Niels Möller) writes: > Mark H Weaver <mhw@netris.org> writes: > >> FYI, I've pushed patches to Guile's git repository (stable-2.0 branch) >> which eliminate the known obstacles to mini-gmp integration. > > Hi, I'm curious if there's been any further progress? I think we dropped the ball here. I would like to do it though. Andy ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#10519: guile and (mini-)gmp 2013-03-02 20:04 ` Andy Wingo 2013-03-02 20:58 ` Mark H Weaver @ 2013-03-02 21:45 ` Niels Möller 1 sibling, 0 replies; 28+ messages in thread From: Niels Möller @ 2013-03-02 21:45 UTC (permalink / raw) To: Andy Wingo; +Cc: 10519, Ludovic Courtès, Torbjorn Granlund Andy Wingo <wingo@pobox.com> writes: > 1. What is the status of mini-gmp? I understand that you use it in GMP > itself, so hopefully mini-gmp is in a good state, upstream. The version bundled with gmp-5.1.1 is fairly solid. The first release, with gmp-5.1.0, had some severe bugs. Testsuite has been improved since. > 2. Has anyone looked at getting mini-gmp into Gnulib? No idea. But I think configuration should be straight-forward: Either you use the "real gmp", or you use mini-gmp. And in the latter case, you know exactly what you have, so there shouldn't be any additional system dependencies. I'd expect the difficult issues to be (i) handling of gmp vs mini-gmp in public headers, API and ABI, and (ii) any features you need which aren't supported in mini-gmp. I guess you should rarely want the "system guile" to be linked with mini-gmp, but use mini-gmp only as an option when guile is bundled with some application. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2016-11-10 19:56 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).