Skip to main content
gamedev.net
🔒 Locked

Aligned memory?

Started by OleKaiwalker 18 replies 3k views
Original Post
OleKaiwalker
OleKaiwalker
Hey, I have read somewhere that access to aligned memory is much faster, but which alignments are giving a boost? When a CPU is 32-bit then a 4 bytes alignment will make sense, but do 8 bytes also make the difference? My reason for asking is that I'm currently boosting my memory mananger and I would like to know whether or not I ought to rewrite it for 4 bytes alignment instead of the current 8 bytes boundary.
Monder
Monder
For x86 architecture 4-byte alignment is what you want.

Though another thing you may want to align to is page boundries (the size of a page isn't fixed so you would probably have to determine it at runtime).
OleKaiwalker
OleKaiwalker
Okay :D thx..

Then I've got some rewriting to do ;)
Conner McCloud
Conner McCloud
An eight byte boundary would just skip every other four byte boundary. You're wasting space, but in terms of memory access you're not punishing anything with your current scheme.

CM
smr
smr
Technically, eight byte alignment is the same as four byte alignment. Eight is divisible by four.
OleKaiwalker
OleKaiwalker
I realized that too.. Stupid, stupid me... Yes, I am kinda wasting space so I'll probably end up using a 4 bytes alignment.
SiCrane
SiCrane
Of course doubles work better when allocated on 8 byte boundaries, so if you ever plan to use those, you might want to stick with your 8 byte system.
randomname
randomname
32bit protsessor likes 4byte alignment
64bit protsessor likes 8byte alignment
MMX/SSE needs 8/16byte alignment.
Cache line size is 32bytes.

Also, often important to know:

For direct un-cached disc access destination/source must have the same alignment. 512bytes usualy.
VMM Memory page size (windows) is 4096bytes. (the most important of the three here).
Memory gets commited (windows again) in 65536byte blocks.

// note, the last 3 can change in future, but they haven't ever so far, so ...
OleKaiwalker
OleKaiwalker
What alignment would you prefer?

If I decide to use 8-byte alignment, then the mananger will be sufficient for a 64-bit system too?
randomname
randomname
As long as every second pc isn't 64bit - i stick with 4bytes (except of course data fields that already need some bigger alignment).

When 64bit starts to get common - just recompile with 8byte alignment if you care (likely, the new pc's are even faster and the little extra to your old program is not worth even to recompile probably).
Alpha_ProgDes
Alpha_ProgDes
Quote:
Original post by Monder
For x86 architecture 4-byte alignment is what you want.

Though another thing you may want to align to is page boundries (the size of a page isn't fixed so you would probably have to determine it at runtime).

quick summary of that if you please [grin]
Beginner in Game Development?  Read here. And read here.  
happy_84k
happy_84k
Quote:
Original post by OleKaiwalker
Hey,

I have read somewhere that access to aligned memory is much faster.


why??
--------------------Ad Astra Per Aspera--------------------
nmi
nmi
Not only the CPU dictates the alignment, but also the width of the data bus, and the cache lines, and...

Maybe you should add a parameter to select the alignment, e.g. a template parameter for compile-time-selection, or a ctor paramter for run-time-selection.

Alignment of 8 byte is usually sufficient, but in some cases like SSE you would better set it to 16 byte.

In any case you can always do your alignment at runtime by prepending some padding bytes to your data. BTW your compiler does a similar thing by reducing the stack pointer...
SiCrane
SiCrane
Quote:
Original post by happy_84k
Quote:
Original post by OleKaiwalker
I have read somewhere that access to aligned memory is much faster.


why??


Long story short: because that's how modern hardware works.

Slightly longer, but still grossly oversimplified version: If the memory isn't aligned properly for the operation being done, it might take multiple "reads" in order to load the value into the register(s). Some processors outright won't load values that aren't properly aligned. IIRC, the MIPS family are like that. Additionally unaligned memory access can hit multiple cache lines, which can really louse up the working set for program execution, especially if your processor has a shared data and instruction cache. The occassional unaligned data value might also straddle two pages, which is like the multiple cache line problem, but on steroids. And so on. The specific details on what can go wrong are processor and OS dependent, but those problems are common on all more recent platforms.
OleKaiwalker
OleKaiwalker
But when allocating memory for a double, why do the alignment have to be at 8 bytes. Why is a 4 byte alignment not sufficient.?
serratemplar
serratemplar
If by double you mean double-precision float, or really double-precision anything, the answer to your question is there...

the more space you use, the more precision you can get. 8-bytes offers more precision than 4...just at a bit more of a speed penalty: two-reads each time instead of one, and you have to commit double the registers to your effort. Depending on the chip you're using (and the number of registers it offers), that could involve more RAM access, which is takes a bit more time still.

But in the end, if you want the precision, likely it's worth the extra few cycles.
fractoid
fractoid
Quote:
Original post by nmi
Not only the CPU dictates the alignment, but also the width of the data bus, and the cache lines, and...
Random thought here, but wouldn't the optimum memory alignment block size for an array of elements of type '_T' usually be equal to "max(sizeof(int), sizeof(_T)"? Since int is defined as a machine-word-sized integer.
Skizz
Skizz
Memory alignment is much more complex than that for the IA32 processors. On P4, Xeon and M processors, you can read most data from any address without any penalty unless it spans a cache line, in which case it can take several cycles. Cache lines are 64 bytes long (32 on P3 and before). So, don't have speed critical structures larger than 64 bytes - at least, don't have data within a structure spanning the 64 byte cache lines, so you may want to align to 64 bytes for speed critical stuff.

But, you really need to profile the application using something like VTune to see is memory access is a real problem for you.

Skizz
OleKaiwalker
OleKaiwalker
According to my common since, allocation of a double on 4-byte alignment or 8-byte will give same result? Anyone willing to explain?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.