gmp's c++ interface / mpz_class

gmp's c++ interface / mpz_class

[Pedro Alves]

Hi!

Zoran and I found a potential need for an integer type with precision of 64-bit + 8-bit, in order to
store bit offsets that can span a whole 64-bits address space.  Instead of rolling our own,
I guess it makes sense to use libgmp, since, well, we already depend on it.  I see that we have:

 /* A class to make it easier to use GMP's mpz_t values within GDB.  */

 struct gdb_mpz
 {

In gdb/gmp-utils.h.  However, we need do to arithmetic on the type, and this wrapper
type doesn't implement operator+, operator-, etc, etc.  I guess we could add those,
as wrappers around mpz_add, etc.  Or use raw mpz_add, etc. directly.  However, I just found
out that GMP already has its own C++ interface:

 https://gmplib.org/manual/C_002b_002b-Interface-General

Before we explore this further, is there an already known reason we shouldn't be using
that interface?

Pedro Alves

Re: gmp's c++ interface / mpz_class

[Pedro Alves]

On 2022-10-14 7:11 p.m., Pedro Alves wrote:

> Zoran and I found a potential need for an integer type with precision of 64-bit + 8-bit, in order to
> store bit offsets that can span a whole 64-bits address space.  Instead of rolling our own,
> I guess it makes sense to use libgmp, since, well, we already depend on it.  I see that we have:
> 
>  /* A class to make it easier to use GMP's mpz_t values within GDB.  */
> 
>  struct gdb_mpz
>  {
> 
> In gdb/gmp-utils.h.  However, we need do to arithmetic on the type, and this wrapper
> type doesn't implement operator+, operator-, etc, etc.  I guess we could add those,
> as wrappers around mpz_add, etc.  Or use raw mpz_add, etc. directly.  However, I just found
> out that GMP already has its own C++ interface:
> 
>  https://gmplib.org/manual/C_002b_002b-Interface-General
> 
> Before we explore this further, is there an already known reason we shouldn't be using
> that interface?

I played with this a bit.  So gmp implements infinite precision by heap-allocating a growing
buffer to hold the value storage.  That's not surprising.  However, what surprised
me was that it _always_ heap-allocates, even for "regular" 8-bytes precision.  I.e., it doesn't
employ SBO (Small Buffer Optimization) to avoid heap allocation until the held value grows
big.  Like, this:

  mpz_class val;

... already calls malloc in the ctor.

Hmm.  Since we don't need infinite precision, it will end up a lot more efficient to roll our
own type, with fixed (or templated) storage size.  Like a simplified version of GCC's wide_int.
Not sure yet whether efficiency really matters in practice, but I suspect it does.

I'd still be curious about GMP's native C++ interface.

Pedro Alves

Re: gmp's c++ interface / mpz_class

[Luis Machado]

On 10/14/22 19:11, Pedro Alves wrote:
> Hi!
> 
> Zoran and I found a potential need for an integer type with precision of 64-bit + 8-bit, in order to
> store bit offsets that can span a whole 64-bits address space.  Instead of rolling our own,
> I guess it makes sense to use libgmp, since, well, we already depend on it.  I see that we have:

Is uint128_t an option (at least temporarily)?

> 
>   /* A class to make it easier to use GMP's mpz_t values within GDB.  */
> 
>   struct gdb_mpz
>   {
> 
> In gdb/gmp-utils.h.  However, we need do to arithmetic on the type, and this wrapper
> type doesn't implement operator+, operator-, etc, etc.  I guess we could add those,
> as wrappers around mpz_add, etc.  Or use raw mpz_add, etc. directly.  However, I just found
> out that GMP already has its own C++ interface:
> 
>   https://gmplib.org/manual/C_002b_002b-Interface-General
> 
> Before we explore this further, is there an already known reason we shouldn't be using
> that interface?
> 
> Pedro Alves

Re: gmp's c++ interface / mpz_class

[Pedro Alves]

On 2022-10-17 11:44 a.m., Luis Machado wrote:
> On 10/14/22 19:11, Pedro Alves wrote:
>> Hi!
>>
>> Zoran and I found a potential need for an integer type with precision of 64-bit + 8-bit, in order to
>> store bit offsets that can span a whole 64-bits address space.  Instead of rolling our own,
>> I guess it makes sense to use libgmp, since, well, we already depend on it.  I see that we have:
> 
> Is uint128_t an option (at least temporarily)?

That is not portable, unfortunately.  It doesn't exist in all compilers, and/or all architectures.

So it's useful to prototype things, but it's not something we can use, because we need this in
core code (DWARF expression evaluation).

We may end up with something like a typedef that maps to int128_t when available,
and to a C++ class emulation when not available, though.

Re: gmp's c++ interface / mpz_class

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

Pedro> In gdb/gmp-utils.h.  However, we need do to arithmetic on the type, and this wrapper
Pedro> type doesn't implement operator+, operator-, etc, etc.  I guess we could add those,
Pedro> as wrappers around mpz_add, etc.  Or use raw mpz_add, etc. directly.  However, I just found
Pedro> out that GMP already has its own C++ interface:

Pedro>  https://gmplib.org/manual/C_002b_002b-Interface-General

Pedro> Before we explore this further, is there an already known reason we shouldn't be using
Pedro> that interface?

I feel sure Joel and I have talked about it, but I don't remember what
reason there was any more.  The warning in the manual is a bit
off-putting, though:

       *Everything described in this chapter is to be considered preliminary
    and might be subject to incompatible changes if some unforeseen
    difficulty reveals itself.*

Pedro> Not sure yet whether efficiency really matters in practice, but I suspect it does.

I'm curious about this as well.

FWIW I've occasionally thought about replacing parts of valarith with GMP.
That way gdb could more easily support 128-bit integers.

Tom

Re: gmp's c++ interface / mpz_class

[Florian Weimer]

* Pedro Alves:

> Hmm.  Since we don't need infinite precision, it will end up a lot
> more efficient to roll our own type, with fixed (or templated) storage
> size.  Like a simplified version of GCC's wide_int.  Not sure yet
> whether efficiency really matters in practice, but I suspect it does.
>
> I'd still be curious about GMP's native C++ interface.

I tried to use it recently in a hobby project, but it turned out to be a
poor fit because it's not integrated well with C++11 and later features
(no move constructors, no rvalue references).  The unconditional use of
malloc is rather off-putting, too.

I'm contemplating to use tagged integers/pointers as the main
representation, with heap allocation only on demand, maybe using the the
mpn* functions directly, or perhaps copy things out of a long-lasting
mpz_t object that's used as a temporary for arithmetic.

For 72-bit integers, that seems a bit over the top, though.

Thanks,
Florian

Re: gmp's c++ interface / mpz_class

[Joel Brobecker]

> Pedro> In gdb/gmp-utils.h.  However, we need do to arithmetic on the type, and this wrapper
> Pedro> type doesn't implement operator+, operator-, etc, etc.  I guess we could add those,
> Pedro> as wrappers around mpz_add, etc.  Or use raw mpz_add, etc. directly.  However, I just found
> Pedro> out that GMP already has its own C++ interface:
> 
> Pedro>  https://gmplib.org/manual/C_002b_002b-Interface-General
> 
> Pedro> Before we explore this further, is there an already known reason we shouldn't be using
> Pedro> that interface?
> 
> I feel sure Joel and I have talked about it, but I don't remember what
> reason there was any more.

Yes, we talked about it for sure, and decided against it, but I don't
remember the reasons, unfortunately :-(.

> The warning in the manual is a bit
> off-putting, though:
> 
>        *Everything described in this chapter is to be considered preliminary
>     and might be subject to incompatible changes if some unforeseen
>     difficulty reveals itself.*

I do remember this comment played a part.

-- 
Joel