[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <536B7378.8070307@gentoo.org>
Date: Thu, 08 May 2014 14:07:20 +0200
From: Luca Barbato <lu_zero@...too.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] add definition of max_align_t to stddef.h
On 08/05/14 00:48, Rich Felker wrote:
> On Wed, May 07, 2014 at 07:12:39AM +0200, Luca Barbato wrote:
>> On 07/05/14 06:29, Rich Felker wrote:
>>> On Wed, May 07, 2014 at 06:14:38AM +0200, Luca Barbato wrote:
>>>> On 07/05/14 05:13, Rich Felker wrote:
>>>>> If we want to achieve an alignment of 8, the above definition is
>>>>> wrong; it will no longer have alignment 8 once the bug is fixed.
>>>>> However I'm not convinced it's the right thing to do. Defining it as 8
>>>>> is tightening malloc's contract to always return 8-byte-aligned memory
>>>>> (note that it presently returns at least 16-byte alignment anyway, but
>>>>> this is an implementation detail that's not meant to be observable,
>>>>> not part of the interface contract).
>>>>
>>>> The current natural alignment shouldn't be 32 for AVX and 16 for SSE ?
>>>>
>>>> Not sure how wasteful would be but it would be surely a boon for the
>>>> applications I'm mostly involved.
>>>
>>> If you're working with data that needs additional alignment, you have
>>
>> That's the part that is annoying, the larger register is 32byte in those
>> platforms.
>
> And it will keep getting larger. Obviously changing the definition of
> types and/or the ABI again and again is not the solution. The solution
> is requesting the alignment you want.
No, but having the correct value for new architectures would be sort of
more correct. Is not that those won't be used.
> BTW note that in the case of audio and video, depending on which
> sample you start at, your data will not be aligned even if the start
> of the buffer is aligned (think video filters working on a sub-image,
> for example).
I know quite well =)
> So in cases like that your code should just handle the
> misaligned head/tail parts separately. Note that GCC (and AFAIK
> clang/llvm) already do this for you with -O3 and a -march that
> supports vector ops.
That isn't the concern at all =)
>>> to use aligned_alloc (C11), posix_memalign (POSIX), or memalign
>>> (legacy). Just assuming the result of malloc will be aligned beyond
>>> the alignment requirements of any standard type is unsafe.
>>
>> That we do already obviously, with the additional fun of not having a
>> realloc matching the mentioned functions in most platforms.
>
> This is really a minor limitation. realloc cannot realistically be
> expected to grow an object in-place in most cases; the only common
> exception is when you're working with new memory at the top of the
> heap and there's nothing else making small allocations that might get
> placed right after your buffer that needs to grow.
>
> In particular, if you're using a sane growth stratgey (geometric),
> almost all calls to realloc are likely to move the buffer, so you're
> just as well off calling malloc (or aligned_alloc) and free yourself.
> The main exception to this might be for HUGE buffers where realloc can
> use mremap with MREMAP_MAYMOVE.
That's what we are doing but as you know quite well, less custom code
the better.
> I think it would complicate the code because now you'd have two cases
> to maintain, the case for implementations that always give excessive
> alignment and the case for ones that don't. And one code path would
> likely bitrot and have bugs.
Not really, we already have platforms doing that so the code is there
and exercised on those.
> In any case, the overhead would be undesirable. If/when I make some
> improvements to malloc and its strategy for returning memory for use
> by other processes (freeing commit charge), I'm also hoping to drop
> the granularity on 64-bit platforms from 32 down to 16 or maybe even
> smaller. There's really no need to store a size_t in the headers for
> chunks which are only used for allocation sizes up to 128k/256k.
I see, nice to know that's the plan =) As said it would had been a nice
to have if it comes for free.
lu
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
