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

Previous Next

To reply to this bug, email your comments to 10519 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: bug-guile <at> gnu.org
Cc: Torbjorn Granlund <tg <at> gmplib.org>
Subject: guile and (mini-)gmp
Date: Sun, 15 Jan 2012 22:22:16 +0100

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.

Message #8 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 05:19:33 -0500

Hi Niels, thanks for looking into this!

nisse <at> 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

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: Mark H Weaver <mhw <at> netris.org>
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 15:06:48 +0100

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.

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

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

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

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 10519 <at> debbugs.gnu.org, Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sat, 28 Jan 2012 10:49:03 +0100

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

Message #20 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: Sat, 28 Jan 2012 05:10:22 -0500

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

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

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

From: Andy Wingo <wingo <at> pobox.com>
To: nisse <at> lysator.liu.se (Niels Möller)
Cc: 10519 <at> debbugs.gnu.org, Torbjorn Granlund <tg <at> gmplib.org>, "Mark H.
	Weaver" <mhw <at> netris.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Fri, 03 Feb 2012 14:40:02 +0100

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/

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10519 <at> debbugs.gnu.org, Torbjorn Granlund <tg <at> gmplib.org>,
	"Mark H. Weaver" <mhw <at> netris.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Fri, 03 Feb 2012 20:56:56 +0100

Andy Wingo <wingo <at> 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.

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

From: Torbjorn Granlund <tg <at> gmplib.org>
To: nisse <at> lysator.liu.se (Niels Möller)
Cc: Andy Wingo <wingo <at> pobox.com>, 10519 <at> debbugs.gnu.org,
	"Mark H. Weaver" <mhw <at> netris.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Fri, 03 Feb 2012 21:01:28 +0100

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

  Andy Wingo <wingo <at> 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

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guile <at> gnu.org
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sat, 04 Feb 2012 23:46:42 +0100

Hello,

Torbjorn Granlund <tg <at> gmplib.org> skribis:

> nisse <at> lysator.liu.se (Niels Möller) writes:
>
>   Andy Wingo <wingo <at> 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.’

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

From: ludo <at> gnu.org (Ludovic Courtès)
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: Sun, 22 Jul 2012 11:00:28 +0200

Hello!

Reviving the discussion, as we’ve been discussing this at the GHM, and
some people would really like to see it happen.  :-)

nisse <at> 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’.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 10519 <at> debbugs.gnu.org,
	Niels Möller <nisse <at> lysator.liu.se>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sun, 22 Jul 2012 11:04:25 +0200

Hi Mark!

Mark H Weaver <mhw <at> netris.org> skribis:

> nisse <at> 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’.

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10519 <at> debbugs.gnu.org, Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Mon, 23 Jul 2012 01:17:51 +0200

[Message part 1 (text/plain, inline)]

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

[guile-mini-gmp.patch (text/x-patch, inline)]

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 @@
  */
 
 
-
+#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"

[Message part 3 (text/plain, inline)]

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

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

From: ludo <at> gnu.org (Ludovic Courtès)
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: Fri, 10 Aug 2012 23:51:00 +0200

Hi Niels,

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

> ludo <at> 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’.

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10519 <at> debbugs.gnu.org, Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sat, 11 Aug 2012 11:37:35 +0200

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

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

From: ludo <at> gnu.org (Ludovic Courtès)
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: Sat, 11 Aug 2012 21:46:10 +0200

Hi,

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

> ludo <at> 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’.

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10519 <at> debbugs.gnu.org, Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sat, 11 Aug 2012 23:50:05 +0200

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

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

From: ludo <at> gnu.org (Ludovic Courtès)
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: Sun, 12 Aug 2012 00:48:21 +0200

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

> ludo <at> 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’.

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

From: Andy Wingo <wingo <at> pobox.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10519 <at> debbugs.gnu.org, Niels Möller <nisse <at> lysator.liu.se>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sat, 02 Mar 2013 21:04:55 +0100

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/

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

From: Mark H Weaver <mhw <at> netris.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10519 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
	Niels Möller <nisse <at> lysator.liu.se>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sat, 02 Mar 2013 15:58:34 -0500

Hi Andy,

Andy Wingo <wingo <at> 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

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10519 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sat, 02 Mar 2013 22:45:14 +0100

Andy Wingo <wingo <at> 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.

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

From: Mark H Weaver <mhw <at> netris.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10519 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
	Niels Möller <nisse <at> lysator.liu.se>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Tue, 05 Mar 2013 14:09:11 -0500

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

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

From: Mark H Weaver <mhw <at> netris.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10519 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
	Niels Möller <nisse <at> lysator.liu.se>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Sun, 17 Mar 2013 20:01:29 -0400

FYI, I've pushed patches to Guile's git repository (stable-2.0 branch)
which eliminate the known obstacles to mini-gmp integration.

     Mark

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 10519 <at> debbugs.gnu.org,
	Niels Möller <nisse <at> lysator.liu.se>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Mon, 18 Mar 2013 10:19:22 +0100

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

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: Mark H Weaver <mhw <at> netris.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 10519 <at> debbugs.gnu.org,
	Ludovic Courtès <ludo <at> gnu.org>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Tue, 26 Mar 2013 09:17:38 +0100

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

Message #80 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: Andy Wingo <wingo <at> pobox.com>, 10519 <at> debbugs.gnu.org,
	Ludovic Courtès <ludo <at> gnu.org>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Wed, 27 Mar 2013 13:00:03 -0400

Hi Niels,

nisse <at> 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

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

From: nisse <at> lysator.liu.se (Niels Möller)
To: Mark H Weaver <mhw <at> netris.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 10519 <at> debbugs.gnu.org,
 Ludovic Courtès <ludo <at> gnu.org>,
 Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Thu, 27 Oct 2016 14:29:54 +0200

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

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

From: Andy Wingo <wingo <at> pobox.com>
To: nisse <at> lysator.liu.se (Niels Möller)
Cc: Mark H Weaver <mhw <at> netris.org>,
 Ludovic Courtès <ludo <at> gnu.org>,
 Torbjorn Granlund <tg <at> gmplib.org>, 10519 <at> debbugs.gnu.org
Subject: Re: bug#10519: guile and (mini-)gmp
Date: Thu, 10 Nov 2016 20:56:18 +0100

On Thu 27 Oct 2016 14:29, nisse <at> lysator.liu.se (Niels Möller) writes:

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

Previous Next

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