内存对齐的目的

Question

无可否认，我不明白。假设你有一个内存字长度为1字节的内存。为什么不能在未对齐的地址(即不能被4整除)的单个内存访问中访问4字节长的变量，因为对齐的地址就是这种情况？

Answer 1

这是许多底层处理器的一个限制。通常可以通过4次低效的单字节读取而不是1次有效的字读取来解决这个问题，但许多语言说明者认为，将它们取缔并强制所有内容对齐会更容易一些。

OP在this link中发现了更多信息。

Answer 2

现代处理器上的存储器子系统被限制为以其字长的粒度和对齐来访问存储器；原因有很多。

速度

现代处理器具有多级缓存，数据必须通过这些缓存；支持单字节读取将使内存子系统吞吐量与执行单元吞吐量紧密绑定(也称为cpu- bound )；这一切都让人想起，由于许多相同的原因，在硬盘驱动器中如何使用PIO mode was surpassed by DMA。

CPU 总是以其字大小(32位处理器上为4字节)读取，因此当您在支持它的处理器上执行未对齐地址访问时，处理器将读取多个字。CPU将读取您请求的地址所跨越的内存中的每个字。这导致访问所请求的数据所需的存储器事务数量放大多达2倍。

因此，读取两个字节的速度很容易比读取四个字节慢。例如，假设内存中有一个结构，如下所示：

struct mystruct {
    char c;  // one byte
    int i;   // four bytes
    short s; // two bytes
}

在32位处理器上，它很可能是这样对齐的：

​

​

处理器可以在一个事务中读取这些成员中的每一个。

假设你有一个结构的打包版本，可能来自网络，为了提高传输效率，它可能看起来像这样：

​

​

读取第一个字节将是相同的。

当你要求处理器提供来自0x0005的16位时，它将不得不从0x0004读取一个字，并将其左移1字节，以将其放入16位寄存器；一些额外的工作，但大多数可以在一个周期内处理。

当你从0x0001请求32位时，你会得到2倍的放大。处理器将从0x0000读入结果寄存器并左移1字节，然后再次从0x0004读入临时寄存器，右移3字节，然后用结果寄存器OR它。

范围

对于任何给定的地址空间，如果体系结构可以假设2个LSB总是0(例如，32位机器)，那么它可以访问4倍多的存储器(2个保存的位可以表示4个不同的状态)，或者相同数量的存储器，其中2位用于类似标志的东西。从地址中去掉2个stride将得到4字节对齐；也称为4字节的LSB。每次地址递增时，它实际上是递增位2，而不是位0，即，最后2位将总是继续为00。

这甚至会影响系统的物理设计。如果地址总线需要的位数减少2位，CPU上的引脚和电路板上的走线就会减少2个。

原子性

CPU可以原子地对存储器的对准的字进行操作，这意味着没有其他指令可以中断该操作。这对于许多lock-free data structures和其他concurrency范例的正确操作至关重要。

结论

处理器的内存系统比这里描述的要复杂和复杂得多；关于how an x86 processor actually addresses memory的讨论可能会有所帮助(许多处理器的工作方式都很相似)。

坚持内存对齐还有许多好处，您可以在this IBM article上阅读到。

计算机的主要用途是转换数据。现代内存体系结构和技术经过几十年的优化，以高度可靠的方式在更多和更快的执行单元之间获取更多数据。

奖励:缓存

我之前提到的另一个性能对齐是在(例如，在一些CPU上) 64B的缓存线上对齐。

有关利用缓存可以获得多大性能的更多信息，请查看此question on cache-line sizes中的Gallery of Processor Cache Effects

对高速缓存线的理解对于某些类型的程序优化可能很重要。例如，数据的对准可以确定操作是否触及一个或两个高速缓存线。正如我们在上面的示例中看到的，这很容易意味着在未对齐的情况下，操作将慢两倍。

Answer 3

您可以使用某些处理器(the nehalem can do this)，但以前所有内存访问都是在64位(或32位)行上对齐的，因为总线是64位宽的，所以您必须一次获取64位，并且以对齐的64位“块”的形式获取这些数据要容易得多。

因此，如果您想要获取单个字节，您可以获取64位块，然后屏蔽掉不想要的位。如果您的字节位于正确的末端，则简单而快速，但是如果它位于64位块的中间，则必须屏蔽掉不需要的位，然后将数据转移到正确的位置。更糟糕的是，如果你想要一个2字节的变量，但它被分成了两个块，那么这就需要两倍的内存访问。

因此，当每个人都认为内存很便宜时，他们只是让编译器将数据与处理器的块大小对齐，以便以浪费内存为代价更快、更高效地运行代码。