Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 5 down vote favorite

4-bytes = word; 8-bytes = 2x word

Then why doesn't the heap just go with 4-byte alignment (because it will be grabbing a word at a time anyway, right?)

If we went with 8-byte alignments, why not 12? 16?

share|improve this question
4  
note: it's defined by the platform. for example: the alignment is 16 on osx. – justin Oct 10 '11 at 19:51
1  
It's a good tradeoff I guess. But you do need other alignments for SSE operations, like 64 or 128 bit boundaries. Some platforms do not support unaligned data "Itanium" and even x86/64 has performance penalties when accessing unaligned data. – Coder Oct 10 '11 at 19:52
@Justin: But don't the 8-byte and 16-byte alignment schemes cause a lot of fragmentation in the heap? Consider allocating 4 integers in the heap: if you did 8-byte alignment then it would take up 32 bytes. 16-byte alignment would take up 64! – Dark Templar Oct 10 '11 at 20:22
@Dark: you're a little confused about alignment - it's only the start of the block that is N-byte aligned. What you do within the block is up to you. Note also that each heap block typically has a small book-keeping overhead associated with it, so alignment padding is just one additional cost per block allocated, and the reason why allocating lots of small blocks may be considered inefficient use of memory. – Paul R Oct 10 '11 at 20:41
It can lead to fragmentation (see also Paul R's explanation). It also reduces the maximum number of allocations a process could utilize (at any given time). To counter this problem, one must often move to 64 bit, use specialized allocators, or reduce the number of heap allocations your programs requires (often using larger, but fewer allocations in exchange). You can also use distributed processing. Fortunately, many programs won't approach these limits. Related: en.wikipedia.org/wiki/Memory_management_unit – justin Oct 10 '11 at 20:59
show 2 more comments

2 Answers

up vote 5 down vote accepted

Efficiency and CPU architecture. I remember when the Alpha chips came out, they could only read memory on 32 bit boundaries. If you wanted to read byte 3, you'd load a 32-bit number then have to rotate the result to isolate the byte you want. A traditional byte-by-byte string compare was quite inefficient in this architecture.

That being said, I'm not sure what modern processors do. It's been a while since I had to deal with this.

share|improve this answer
Hmm.. but these are 32-bit machines. I'm not sure why we need to access in 64-bit patterns for the heap? – Dark Templar Oct 10 '11 at 20:20
No, the Alpha was a 64 bit CPU. Alignment requirements do not always coincide with register widths, especially when a CPU has registers of varying width. – MSalters Oct 11 '11 at 11:20
MSalters - The Alpha was 64 bit processor but memory reads were aligned on 32 bit boundaries (99% sure). I was working for a company who implemented their own VM and we were considering aligning our strings on 4-byte boundaries to allow faster comparisons. That being said, this was almost 20 years ago and my brain is rapidly failing. – dave Oct 11 '11 at 18:41
up vote 0 down vote

Short answer is "It doesn't". The alignment is associated with the implementation details of the heap manager, nothing more. Your heap manager may have an alignment requirement for various reasons, such as efficiency, architecture, whim of the writer or what ever. If you have a reason to care, please share it with us.

BTW:

4-bytes = word 8-bytes = 2x word

This is an assumption, is incorrect, and has lead to many varied, sometimes expensive and always inexcusable software porting problems. The size of a word depends on the hardware architecture, OS, language and compiler being used.

share|improve this answer
for IA32 a word is 32-bits, pretty straightforward...? – Dark Templar Oct 10 '11 at 20:54
Maybe, but absolutely irrelevant, unless you are designing a malloc package. – Ingo Oct 10 '11 at 22:35
Doesn't the size of a word depend only on the CPU arch? – Yam Marcovic Oct 11 '11 at 0:00
A 'word' is normally used to describe the natural size of a block of data on for the specific CPU, however, there is no standard definition for what size it is. If you explicitly require an 8 bit byte, use the term octet, and explicitly define a word as a certain number of octets. Essentially far to many developers stuff things up making grossly incompetent assumptions that 4 bytes = a word etc......it's 2011, we have had 50 years to get this basic Comp Sci stuff right. – mattnz Oct 11 '11 at 4:20
Windows still calls 32 bits a DWORD (Double Word), and WORD remains 16 bits. – MSalters Oct 11 '11 at 11:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.