Reputation: 423
So I read that when variables are declared in c++ if you want to get the optimum cache reads the memory should stick to its natural alignment. Example:
int a; // memory address should end in 0x0,0x4,0x8,0xC
int b[2]; // 8 bytes 0x0,0x8
int b[4]; // 16 bytes 0x0
But in practice these variables do not follow the "natural alignment" rules, a 16 byte variable was residing at a memory address that ended in 0xC. Why is this ?
Upvotes: 5
Views: 6089
Reputation: 4812
According to Intel® 64 and IA-32 Architectures Optimization Reference Manual (section B.4.5.2 Assists),
32-byte AVX store instructions that span two pages require an assist that costs roughly 150 cycles.
Upvotes: 1
Reputation: 3073
C++ won't align anything on the cache line because for all intents and purposes it doesn't know there is a cache.
If you want something aligned on a 16-byte boundary try posix_memalign()
for things on the heap, or (if using GCC) on the stack, int x __attribute__ ((aligned (16)))
. In C++11 there is the alignas specifier.
I don't know a way to call new()
with a guaranteed alignment though.
Upvotes: 4
Reputation: 7374
Natural memory alignment generally refers to the alignment of individual variables, not arrays of variables. Thus an array of 4 byte integers (as you apparently have above) is naturally aligned to a 4 byte boundary and not to the 16 byte boundary.
Natural memory alignment usually pertains to how the CPU's load/store instructions are architected and implemented, not the size of cache lines. The CPU does not load whole arrays at a time (except for vector loads). Thus the CPU doesn't really care if an integer it is loading is part of an array or not.
Vector loads, which do load small arrays at the same time, often do have stricter alignment requirements. For example, in order to do an aligned vector load on an x86, the item must be aligned to 16 bytes.
Upvotes: 7