Optimal struct layout template?

Don nospam at nospam.com
Thu Dec 18 08:08:12 PST 2008


Denis Koroskin wrote:
> On Thu, 18 Dec 2008 01:38:32 +0300, Sergey Gromov 
>> Thu, 18 Dec 2008 00:21:58 +0300, Denis Koroskin wrote:
>>> On Thu, 18 Dec 2008 00:12:18 +0300, Sergey Gromov 
>>>> Tue, 16 Dec 2008 10:09:41 +0100, Don wrote:
>>>>> struct Foo { double, int } // 12 byte size, wants 8-byte alignment.
>>>> Foo.sizeof is 16.
>>> It is 12 with align(1) (I see no problem with it).
>> With align(1) the Foo.alignof is 1 so there is no problem to talk about.
> No, there is. You should have structure as follows:
> 
> align(1):
> struct Foo
> {
>     char c;
>     double d;
>     short s;
>     bool b;
> }

[snip]

> so that Foo.d.alignof == 8. Align(1) is still necessary so that 
> Foo.sizeof == 12.

Sergey is correct to the extent that in DMD, x.alignof <= x.sizeof for 
any x, and also x.sizeof is always an integer multiple of x.alignof.
When you assume that DMD is correct, then the simple ordering by 
.alignof indeed gives an optimal solution.
But these values *don't* reflect the machine behaviour.

real.alignof is 2. But it's significantly faster (factor of 2) on most 
x86 machines to have real aligned to 16.

These effects are not captured by the .alignof property for structs. To 
capture it in the Foo example, you'd need (for example) a 
Foo.memberalignof property, and a Foo.memberalignoffsetof property.
But you could reasonably argue that if you're specifying align(1) then 
alignment is not important.
The simple algorithm may well be good enough.
(And note that you can use radix sort -- alignof can only be 1, 2, 4, 8, 
or 16 -- so it's in O(n) not O(n lg n)).

Interestingly, this 'internal alignment' applies to function alignment, 
as well. D allows you to specify that a function be aligned to (for 
example) a 16-byte boundary. This is hardly ever useful; usually what 
you want is for the innermost loop to be aligned. And instead of a pile 
of nops before the loop, you'd like the function start address to be 
adjusted.



More information about the Digitalmars-d mailing list