Richard Cownie (tich@pobox.com) on 1/13/11 wrote:
>
>About a year ago I redesigned a hashtable class and
>spent a while trying out different code sequences and
>data layouts on Nehalem-based machines. The conclusion
>of that effort was the penalty for misaligned accesses
>within a cacheline appeared to be very small;

It should be zero within the L1 access size. Which is
usually not a whole cacheline, but half or a quarter line.

(Yes, there's the hardware cost of the cross-bar, but that
is not a cycle cost).

So there is literally zero cost for most unaligned
data on x86. For a bank crossing thing you usually have
just an extra cycle or two. And for a page crosser you
then obviously have the extra TLB lookup (and I think you
might end up with a replay depending on microarchitecture).

I don't think this is even new to Nehalem. Afaik, it's
true of just about every x86 ever produced.

And yes:

> and that
>for what I was doing (essentially storing an array of
>48bit values) it would be fastest to pack the values
>tightly and do read accesses with non-aligned 64-bit
>reads (followed by masking as necessary).

Some people still haven't learnt that the real cost in
computing today is cache misses, and unaligned data can
be a very good thing if it means you have denser data
structures.

There are also many cases where the data has an external
format definition, and you want lots of unaligned accesses
for that reason (rather than copy it into some aligned
structure or doing byte-wide accesses - and rather than
using two "load high/low" instructions)

Not doing unaligned data well is crazy.

Intel tried the "only aligned" route. Look at MMX/SSE,
where you had hardware people trying to push the whole
"natural alignment" crap. It was a mistake. They fixed
it.

>In the light of that experience - which was somewhat
>surprising to me - I would suggest that "code with lots
>of misaligned accesses typically doesn't run fast"
>may be incorrect for Nehalem and later.

I really think it's "just about any x86".

Linus