When I do new void[](n)
, is that buffer allocated with an alignment of 1 or what are the guarantees? How can I set an alignment? Also, is the alignment of any type guaranteed to be a power of 2?
Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
September 30, 2022 How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
September 30, 2022 Re: How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | On Friday, 30 September 2022 at 15:57:22 UTC, Quirin Schroll wrote: >When I do https://dlang.org/library/core/stdc/stdlib/aligned_alloc.html It's the C func, so check C lib doc. |
September 30, 2022 Re: How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
Posted in reply to mw | On Friday, 30 September 2022 at 16:23:00 UTC, mw wrote: >On Friday, 30 September 2022 at 15:57:22 UTC, Quirin Schroll wrote: >When I do https://dlang.org/library/core/stdc/stdlib/aligned_alloc.html It's the C func, so check C lib doc. and then use emplace on the C-alloc-ed memory. |
October 01, 2022 Re: How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | On Friday, 30 September 2022 at 15:57:22 UTC, Quirin Schroll wrote: >When I do It is guaranteed an alignment of at least 1 because Arrays and aggregate types ( How can I set an alignment? If the desired alignment is However, if you may need higher alignment than the maximum guaranteed to be available from the allocator, or you are not writing strongly typed code to begin with, as implied by your use of
However, aligning memory outside of the allocator itself like this does waste up to
> Also, is the alignment of any type guaranteed to be a power of 2? In practice, yes. On Friday, 30 September 2022 at 16:23:00 UTC, mw wrote: >https://dlang.org/library/core/stdc/stdlib/aligned_alloc.html It's the C func, so check C lib doc. https://en.cppreference.com/w/c/memory/aligned_alloc Note that common implementations place arbitrary restrictions on the alignments and sizes accepted by (If this all seems overly complicated, that's because it is. I have no idea why allocators don't just build in the logic above; it's extremely simple compared to the rest of what a good general-purpose heap allocator does.) |
October 01, 2022 Re: How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
Posted in reply to tsbockman | On Saturday, 1 October 2022 at 00:32:28 UTC, tsbockman wrote: >
Oops, I forgot that
(This also eliminates the |
September 30, 2022 Re: How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | On 9/30/22 11:57 AM, Quirin Schroll wrote: >When I do In practice, it's not necessarily a power of 2, but it's at least 16 bytes. In general there are very few types (maybe vectors?) that need alignment more than 16 bytes. The list of bit sizes is currently here: https://github.com/dlang/dmd/blob/82870e890f6f0e0dca3e8f0032a7819416319124/druntime/src/core/internal/gc/impl/conservative/gc.d#L1392-L1414 -Steve |
October 01, 2022 Re: How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Saturday, 1 October 2022 at 01:37:00 UTC, Steven Schveighoffer wrote: >On 9/30/22 11:57 AM, Quirin Schroll wrote: >Also, is the alignment of any type guaranteed to be a power of 2? In practice, it's not necessarily a power of 2, but it's at least 16 bytes. Types always require some power of 2 alignment (on any sensible platform, anyway), and it is usually less than 16 bytes - typically The fact that the current GC implementation apparently has a minimum block size of 16 bytes, and that minimum size blocks are always size-aligned, is not guaranteed by the public API and should not be when requesting memory for something that the type system says only requires an alignment of D and C both have formal ways to communicate alignment requirements to the allocator; people should use them and not constrain all future D GC development to conform to undocumented details of the current implementation. >In general there are very few types (maybe vectors?) that need alignment more than 16 bytes. 256 bit SIMD (AVX/AVX2) and 512 bit SIMD (AVX512) I don't know any other examples off the top of my head. >The list of bit sizes is currently here: I'm pretty sure those are in bytes not bits. >That's not a list of alignments, it is block sizes for some GC memory pools. The alignment of each block depends on the alignment of its pool, not just its size. It's not immediately obvious from the context, but I suspect the pools are actually page aligned, which would mean that the non power of 2 sized blocks are not consistently aligned to their own sizes. Regardless, it's not part of the public API, so it could change without warning. |
October 01, 2022 Re: How to do alligned allocation? | ||||
---|---|---|---|---|
| ||||
Posted in reply to tsbockman | On 10/1/22 12:57 AM, tsbockman wrote: >On Saturday, 1 October 2022 at 01:37:00 UTC, Steven Schveighoffer wrote: > >The list of bit sizes is currently here: I'm pretty sure those are in bytes not bits. Yes, I meant bytes, sorry. >That's not a list of alignments, it is block sizes for some GC memory pools. The alignment of each block depends on the alignment of its pool, not just its size. Pools are all page multiples. Each pool is split equally into bin sizes, from that list. >Regardless, it's not part of the public API, so it could change without warning. Hence the "in practice" qualifier. Is it theoretically possible for a GC implementation to use smaller bin sizes, but it will never happen. Consider that in small bins ( < 1 page ), no two bins are concatenated together. So if you had a bin of size 1, it means you would only allocate one byte blocks, never combining them. Again, these are all implementation details, that likely will never change. -Steve |