Size of a structure : Structure Padding

[Kislay]

case 1 :
struct s
{
char c1[6]; // 8
double d; // 8
int i1; // 4
char c2[2]; // 4
int i2; // 4
};

case 2:
struct s
{
char c1[6]; // 8
double d; // 8
int i1; // 4
char c2[2]; // 4
int i2; // 4
float f // 4
};

According to the rules of structure padding shouldn't the size of the
above structure be 28 bytes (for a 32 bit compiler , I am using DEV-C+
+) ? But I got 32 as the answer , using sizeof . And when I added
"float f" to the structure , I was getting the same answer , 32 .
Well , if 32 is right instead of 28 in the first case , then after
adding a float , shouldn't it become 36 ? But even in case 2 , its
32 . Is there more to structure padding than simple clubbing together
in groups of 4 ? Somebody please shed some light ?

[Kislay]

Thank you

[Kenneth Brody]

Kislay wrote:

>
The individual units of the structure occupy the number of bytes they
are supposed to , and the extra bytes , if any are the padded ones .
So far so good . But the padded bytes will never be free to be used
for anything else , right ? So it can be said that on the whole the
structure is occupying the actual bytes plus the padded ones . The
padded bytes go waste . Consider the following structure ,
struct s
{
char c[2];
double d;
};
c occupies 2 B , d occupies 8 & the structure s occupies 16 (6 padded
bytes) . If these padded bytes cannot be put to any use , isn't it a
big waste of memory . Is structure padding really worth that ?

Define "worth it".

Consider a platform with a 64-bit memory bus. That is, all access
to memory is done 8 bytes* at a time. Consider further that, should
a read to a non-aligned double be performed, this would take two
reads from memory rather than one. Consider further still, that a
write to a non-aligned double would, rather than being just a single
write, need two reads plus two writes. That's at least a 100%
performance hit on reads, and 300% on writes.

Next, consider a similar platform which, rather than allowing the
non-aligned access, instead causes a hardware exception. On such a
platform, this probably means any program using such a construct
would crash. On other platforms, an exception handler takes over
and allows the access to happen, by executing code which reads the
two aligned 8-byte values and pulls out the appropriate bytes to
be assembled and returned. Or, for writes, reads the two values,
combines the bytes as needed, and writes both values back out.
Imagine the performance hit on this platform. It is quite easy to
forsee a 10,000% performace hit or more.

(Note: I have worked on platforms with all three of the above
scenarios, though not necessarily 8-byte alignment. And note, too,
that except for the "crash on non-aligned values" system, the C
compilers I used had an option to change the alignment used.)

So, once again, define "worth it".
* - Okay, so I'm assuming 8-bit bytes here. Sue me.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Gordon Burditt]

>Consider the following structure ,

>struct s
{
char c[2];
double d;};

c occupies 2 B , d occupies 8 & the structure s occupies 16 (6 padded
bytes) . If these padded bytes cannot be put to any use , isn't it a
big waste of memory .

If the code is running on a processor which can only access doubles if
they are on an 8-byte boundary, then it's clearly not a waste at all -
the program simply wouldn't work without it.

I'm not sure I believe there are platforms where it "simply wouldn't
work" in a way the compiler writer couldn't work around (perhaps
very painfully). Accessing a (possibly) misaligned double can be
done by memcpy()ing to a temporary variable that is aligned, and
using the value there. Storing values can be done in reverse: store
to an aligned temporary, then memcpy() to the (possibly) misaligned
location. All this can be done automatically by the compiler. It
will likely cause a HUGE performance penalty, but it can be done.
You also probably get the performance penalty if it MIGHT be
misaligned rather than only if it IS misaligned.

It still comes down to a tradeoff: execution time vs. memory use.

>If the code is running on a processor which can access doubles much
more efficiently if they are on an 8-byte boundary, but is able to
access them more slowly if they are on another boundary, then whether
or not it is a waste (and how big a waste it is) depends entirely on
how important speed of execution is to you compared to memory size.

I think all processors that can implement memcpy() fall in this category,
but it may be the compiler, not the hardware, that determines the speed.

>If the code is running on a processor which can access doubles equally
efficiently on any boundary, then it would be a big waste - but I
wouldn't expect the compiler to use any padding for that processor.