An interesting structure!
mike at halcrow.us
Mon Nov 28 17:28:17 MST 2005
On Mon, Nov 28, 2005 at 12:07:18AM -0700, Shane Hathaway wrote:
> Laurent R wrote:
> > I found an interesting thing about the structure. It is defined just like:
> >U16 A;
> >bool B;
> >U32 C
> >for the application software, it may be coded with c and c++. the
> >compiler is gcc version 3.3.2
> > Now, the interesting thing arise, for c++ program, the value of
> >sizeof(STR) is 8, but for c program, it is 12.
> Normally, the size is not important. The compiler chooses a size
> for types like "int" and "bool" that balances speed and memory
> consumption on the specific target platform.
Specifically, it has to do with cache alignment. In most
architectures, if my memory serves correctly (no pun intended), the
smallest amount of data that can be transfered between the L2 cache
and the L1 cache is an entire cache line, and the smallest amount of
data that can be transfered between the L1 cache and the register file
is one block/word. Hence, in general, you want the elements of your
structs to be word-aligned for cache performance reasons. Factors that
come into consideration, from a performance point of view, include
block replacement in the L1 cache, L1-L2 cache coherency, the victim
cache, store merge buffers, and other such architectural structures of
the sort. If you have lots of ``extra'' data in any given block, then
you negate the benefit of intelligent cache block replacement, for
example, when you write to several of those data elements that all map
to the same block in the L1 cache. In addition, you increase the risk
introducing pipeline stalls due to store buffer conflicts when the
same block is written to by temporally adjacent speculative
instructions (maybe modern processors are intelligent enough to get
around that somehow, but it has been a problem in many chips). In
general, unless you are really hurting for memory, I would recommend
that you do what your compiler suggests for your target architecture.
And put your larger data elements near the beginning of your structs;
that makes it easier for the compiler to optimize the placement of the
elements in the cache.
Michael A. Halcrow
Security Software Engineer, IBM Linux Technology Center
GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C 20F5 DB40 8531 6DCA 8769
Cogito cogito, ergo cogito sum.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 481 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20051128/b25623fb/attachment.bin
More information about the PLUG