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.