2
\$\begingroup\$

I've found the memory alignment is always equal to power of 2. Google said that such amount of alignment allows modern computers to perform read more fast. Ok, what exactly problem we would gain if we set amount of alignment is power of 3? To be more specific I would like to know what exact hardware architect aspect require the alignment to be a power of 2.

\$\endgroup\$
  • 1
    \$\begingroup\$ The reason for using powers of 2 is that internally CPU's are using binary coding. In binary is very easy to encode powers of 2, basically switch the 1 one wire to the left. \$\endgroup\$ – jnovacho Oct 5 '14 at 13:19
5
\$\begingroup\$

Modern computer memory is conceptually addressed as bytes, but the real hardware transfer is done in a multiple (a power of 2) of bytes. To do this, the last few bits of the address do not take part in the actual transfer, but are (optionally) used inside the CPU to select one (or more) of the transferred bytes.

A consequence of this scheme is that what is transferred is a block of bytes (the size is a power of 2) that is aligned at a multiple of the block size. If the CPU wants a data block that does not fit this constraint, more than one block read is needed, and the CPU must reshuffle the content of the blocks to get the data it needs. A CPU can do without such reshuffling hardware (and the associated loss of time) by requiring that data is suitably aligned.

In short: 2^N alignment matches what is easy and fast in hardware.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ 80x86 processors have always been able to do unaligned byte reads, unlike older ARM architecture, which would throw an exception. However in the case of the 80x86., there was a performance penalty -- but not anymore. In the article Data alignment for speed: myth or reality? experiments show there is no longer any penalty whatsoever reading unaligned data with the Core7 processor. \$\endgroup\$ – tcrosley Oct 6 '14 at 12:03
  • \$\begingroup\$ In addition to the aligned nature of data access chunks, there is also the constraint of cache block chunks (having to check two tags) and page granularity (having to check two TLB entries). While not all unaligned accesses will cross such boundaries (just as smaller accesses need not cross access chunk boundaries), handling such block and page crossings adds complexity. \$\endgroup\$ – Paul A. Clayton Oct 6 '14 at 12:43
1
\$\begingroup\$

Try counting up in multiples of 10. It's very easy: 10, 20, 30, 40, 50, 60, ...

Now try counting up in multiples of some other number, like, say, 7: 7, 14, 21, 28, 35, 42, ...

You'll notice that, in base 10, it's a lot easier to count up in multiples of 10 (or 100 or 1000) because you can just count up in increments of one and append one or more zeros to the end of the numbers. Counting up in multiples of 7 is a lot harder, because there's no such easy rule, and you'll end up having to do some non-trivial arithmetic (especially after you get past the small multiples of 7 you may have memorized while learning the multiplication table in preliminary school).

It works the same way for computers, except that all modern computers use base 2 instead of base 10 internally (because binary digits are easy to represent electronically; you just have two states: 1/0, on/off, high/low). Thus, for computers, counting in steps of 2 (or 4 or 8 or 16, etc.) is very easy, whereas counting in steps that are not powers of 2 requires more complex arithmetic.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Your example only works in base 10. In base 7, counting up by 7 is just as trivial. \$\endgroup\$ – markt Oct 5 '14 at 23:38
  • 1
    \$\begingroup\$ @markt: Exactly. I used base 10 in the example, because (most) humans count in base 10. Computers count in base 2, which is why it's easy for them to count up by powers of 2, but harder to count up by, say, 3 or 7 or 10. \$\endgroup\$ – Ilmari Karonen Oct 6 '14 at 11:35
  • \$\begingroup\$ I get that, but my point was that it's only hard to count in 7's in base 10 because it's not base 7. You're not incorrect, but your example is bad because it doesn't (clearly) explain that the problem isn't the values, it's the non-ideal match between the values and the base that they're expressed in. \$\endgroup\$ – markt Oct 6 '14 at 12:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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