This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 20 Feb 2015 14:20:03 +0000
- Subject: [Bug libstdc++/65122] std::vector doesn't honor element alignment
- Auto-submitted: auto-generated
- References: <bug-65122-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Benoit Jacob from comment #13)
> (In reply to Richard Biener from comment #12)
> > (In reply to Benoit Jacob from comment #11)
> > > (In reply to Richard Biener from comment #10)
> > > > But ::operator new(std::size_t) could always return memory aligned for the
> > > > most over-aligned type? Thus our default new implementation could use
> > > > posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)?
> > >
> > > The problem is there are lots of use cases for really high alignment: AVX
> > > brings uses of 32-byte alignment, and cache lines are typically >= 64 byte
> > > aligned. So alignas has to support at least 64 or 128 byte alignment to
> > > support cache friendly code, and even without that, it would have to support
> > > at least 32 byte alignment for AVX vectorized code.
> > >
> > > Making all allocations that large would lead to substantial allocator slop.
> > > For example, jemalloc has a quantum of 8 or 16 byte depending on whether the
> > > arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a big
> > > difference.
> >
> > Though does it really matter in practice? Tiny allocations would not suffer
> > because of the MIN (align, size), so the worst-case is max-align + 1
> > allocations. Btw, you could as well try MIN (align, size & -size),
> > thus assume that the allocation size is N * alignof ().
>
> Oh, I was missing the MIN (size, BIGGEST_ALIGNMENT) part of your proposal.
> So you're right, that nicely takes care of tiny allocations. Correct also on
> MIN (align, size & -size) (though I have to trust your bit wizardry here)
> so that neatly exploits the low bits of the size parameter to infer the
> alignof --- sounds very good to me!
That trick of course requires you to not "optimize" your allocations manually
to omit tail padding in aggregates (or manually compute allocation sizes).
Or use
struct { avx512vector x; char c; } __attribute__((packed,aligned(64)));
which has alignment 64 and size 65... (of course arrays of such objects
are ill-defined)