_mp_alloc to long int
Hans Åberg
haberg-1 at telia.com
Thu Sep 29 20:34:28 CEST 2022
[Resent due to crash of mailman.]
> On 29 Sep 2022, at 17:38, Torbjörn Granlund <tg at gmplib.org> wrote:
>
> 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.
Right, I overlooked this. You would have to merge the two sizes into one.
> 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).
This is a good point.
In C++, if changing sizes to size_t, both std::atomic_ref<A>::required_alignment and alignof(A) are 8. But for the type B, which corresponds to __mpz_struct, std::atomic_ref<B>::required_alignment = 16 and alignof(B) 8.
struct A {
size_t a;
size_t b;
size_t* p;
};
std::atomic_ref<A>::required_alignment: 8
alignof(A): 8
struct B {
int a;
int b;
size_t* p;
};
std::atomic_ref<B>::required_alignment: 16
alignof(B): 8
More information about the gmp-discuss
mailing list