_mp_alloc to long int
Torbjörn Granlund
tg at gmplib.org
Thu Sep 29 17:38:15 CEST 2022
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
More information about the gmp-discuss
mailing list