byte alignment...

I don''t know about other compilers but MSVC automatically aligns data structures where it sees fit. The only time I need to temper with the defaults was when I wrote routines for my own file format. In that case I needed to disable alignment to write the data structures to the file properly.

If anyone can think of another practical use, I''d like to hear about it.

quote:

---

Original post by original vesoljc
just wondering how far to go? is it worth it to align an object from 15 to 16 bytes, or 30 to 32, or 100 to 128 or even 450 to 512 bytes?!?
does alignemnt count if u use normal (stack?) variables and dynamicly allocated variables (heap?)?!?

---

This is all assuming x86 hardware:

As someone earlier said, alignment should be along word (2 byte) and doubleword (4 byte) boundaries, depending on the size of the variable.

Alignment is especially important on the stack; if the stack pointer isn''t aligned, then every subsequent stack access will take up to two extra memory cycles. This can quickly add up. Any good compiler should align data in the frame buffer by default.

In assembly programming, function entry points should be explicitly doubleword aligned. Again, a compiler for a HLL should do this by default.

Dynamically allocated memory should be aligned automatically by the memory manager. If it isn''t, there''s not much that can be done about it. Given the overhead of dereferencing the the pointer, whether or not it is aligned properly is not a big issue, though of course if it is aligned it is generally better.

For more on when data alignment is or is not important, see the online version of Abrash''s Graphics Programming Black Book, Chapter 11. This book remains a valuable reference even five years after it was published, BTW, and I strongly recommend reading through it as much as you can, though it is very, very long.

quote:

---

If anyone can think of another practical use, I''d like to hear about it.

---

Memory usage. If you have a structure array with millions of elements, you won''t want it padded, as it will take a lot more memory for nothing.

quote:

---

Original post by Yann L
Memory usage. If you have a structure array with millions of elements, you won''t want it padded, as it will take a lot more memory for nothing.

---

Won''t it be faster though?... x86 processors are 32-bit, so they will work better with a struct aligned to 32 instead of say 31. Most computers today have plenty of memory to spare, so if you''re not worried about size, you might consider adding in a #pragma pack directive to optimize performance.

I am a Jedi, like my father before me.

quote:

---

Original post by kill
The only time I need to temper with the defaults was when I wrote routines for my own file format. In that case I needed to disable alignment to write the data structures to the file properly.

---

Based on a loose interpretation of the word "properly", I guess.

quote:

---

Won''t it be faster though?... x86 processors are 32-bit, so they will work better with a struct aligned to 32 instead of say 31. Most computers today have plenty of memory to spare, so if you''re not worried about size, you might consider adding in a #pragma pack directive to optimize performance.

---

I was talking about really much data. For example, I''m currently working on a radiosity algorithm that needs to store 100 million patches. A patch is a very simple structure, currently taking 11 bytes. That''s 1.1GB RAM only for that array. If I''d only pad it by one byte (to 12), it would have taken 100MB more.

And yes, 4 byte alignment will of course theoretically be faster. But when talking about those amounts of memory, then cache misses will totally outweight any alignment benefits. Aligning might even cause swapping in those cases, definitely not desirable

And applications using that big structures aren''t so uncommon, esp. in graphics, simulation and scientific domains. Padding and alignment is good, but there are exceptions were it can cause more harm than good.

4-byte alignment isn't (wasn't) the only good thing. In an old game of mine, I aligned the structs to 2^n. For example, from ~50 to 64. It seemed to boost the game speed by at least 20%, when I had thousands of bullets flying around.

It was mostly because my design was pretty bad and I had lots of random accessing to arrays. Without 2^n alignment, the computer has to calculate
indexed_address = address + sizeof(the_struct) * index
but with 2^n alignment it can be done like
indexed_address = address + (index << n)

Things might've changed since then, though. From what I've heard, shifting isn't that much faster on new processors.

[edited by - Hanz on November 7, 2002 4:36:35 AM]