_mp_alloc to long int

[Torbjörn Granlund]

Hans Åberg <haberg-1 at telia.com> writes:

  At least in C++, there may be no memory savings with smaller ints due
  to alignment requirements. In GCC 12 (MacOS 12),
  __STDCPP_DEFAULT_NEW_ALIGNMENT__ is 16, meaning that operator new will
  allocate multiples of 16 bytes.

We have a pointer, two size integers.

On a 64-bit machine, these will currently be 8+4+4 = 16 bytes.
Worst-case extra alignment cost = 0.

If the size fields are instead 8 bytes each, we get, 8+8+8 = 24 bytes.
Plus a worst-case extra alignment cost of 8.

So in the worst case, twice as much memory is needed for mpz_t.

Now, let's not interpret __STDCPP_DEFAULT_NEW_ALIGNMENT__ as if every
mpz_t is forced into that aligment.  Most of these are put on the stack,
and should just get 8-byte aligned (even if, which I think is true, the
stack pointer is 16-byte aligned at function entry).

That means that mpz_t will be 50% larger for typical usages.  Even an
malloc'ed vector of mpz_t's should only incur 50% size penalty.

But if somebody malloc's individual mpz_t variables, then they will pay
100% (plus whatever metadata structures needed by malloc).

(We have experimental code which makes the _mp_alloc field use a 16 bits
floating-point number and the _mp_size field use a 48-bit integer.
I.e., the _mp_size field steals 16 of _mp_alloc's bits.  Well-behaved
programs should be binary compatible with such changes, and the mpz_t
variables will not need more space.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622