优化 C++ 中的成员变量顺序

Question

我正在阅读游戏的博客文章 Introversion 的编码员，他正忙着试图挤压每一个CPU 勾选他可以退出代码。 他随手提到的一个技巧是

“重新排序a的成员变量 分为最常用和最不使用的类别。”

我不熟悉 C++，也不熟悉它的编译方式，但我想知道

1. 这个说法是否准确？
2. 如何/为什么？
3. 它适用于其他（编译/脚本）语言吗

我我知道这个技巧节省的（CPU）时间是最少的，这并不是一个破坏性的事情，但另一方面，在大多数函数中，很容易识别哪些变量将是最多的。常用的，默认就以这种方式开始编码。

Answer 1

这里有两个问题：

• 是否以及何时将某些字段放在一起是一种优化。
• 实际怎么做呢。

它可能有帮助的原因是，内存以称为“缓存行”的块的形式加载到 CPU 缓存中。 这需要时间，一般来说，为对象加载的缓存行越多，所需的时间就越长。 此外，更多的其他内容会被从缓存中抛出以腾出空间，这会以不可预测的方式减慢其他代码的速度。

高速缓存行的大小取决于处理器。 如果它与对象的大小相比很大，那么很少有对象会跨越缓存行边界，因此整个优化是相当无关紧要的。 否则，有时您可能会只将对象的一部分放在缓存中，而将其余对象放在主内存（或者可能是 L2 缓存）中。 如果您最常见的操作（访问常用字段的操作）对对象使用尽可能少的缓存，那是一件好事，因此将这些字段分组在一起可以让您更有可能发生这种情况。

一般原则称为“引用局部性”。 程序访问的不同内存地址越接近，获得良好缓存行为的机会就越大。 通常很难提前预测性能：同一架构的不同处理器型号可能会有不同的行为，多线程意味着您通常不知道缓存中会包含什么，等等。但是可以谈论什么是大多数情况下可能会发生。 如果您想了解任何事情，通常必须对其进行测量。

请注意，这里有一些问题。 如果您使用基于 CPU 的原子操作（C++0x 中的原子类型通常会这样做），那么您可能会发现 CPU 锁定整个缓存行以锁定字段。 然后，如果您有多个紧密相连的原子字段，不同的线程在不同的核心上运行并同时对不同的字段进行操作，您会发现所有这些原子操作都是序列化的，因为它们都锁定相同的内存位置，即使它们“在不同的领域进行再经营。 如果它们在不同的缓存行上运行，那么它们就会并行工作，并且运行得更快。 事实上，正如 Glen（通过 Herb Sutter）在他的回答中指出的那样，在一致缓存架构上，即使没有原子操作也会发生这种情况，并且可能会彻底毁掉你的一天。 因此，在涉及多个核心的情况下，引用局部性不一定是一件好事，即使它们共享缓存。 您可以预期它是这样的，因为缓存未命中通常是速度损失的一个原因，但在您的特定情况下是严重错误的。

现在，除了区分常用字段和不常用字段之外，对象越小，它占用的内存（因此缓存也就越少）就越少。 这对于各方来说都是个好消息，至少在没有激烈争用的情况下是如此。 对象的大小取决于其中的字段，以及必须在字段之间插入的任何填充，以确保它们针对架构正确对齐。 C++（有时）根据字段声明的顺序对字段在对象中必须出现的顺序施加限制。 这是为了使低级编程更容易。 因此，如果您的对象包含：

• 一个 int（4 字节，4 对齐），
• 后跟一个 char（1 字节，任意对齐），
• 后跟一个 int（4 字节，4 对齐），
• 后跟一个 char（1 字节，任意对齐 ） ）

那么这很可能会占用内存中的 16 个字节。 顺便说一句，int 的大小和对齐方式在每个平台上并不相同，但 4 很常见，这只是一个示例。

在这种情况下，编译器将在第二个 int 之前插入 3 个字节的填充，以正确对齐它，并在末尾插入 3 个字节的填充。 对象的大小必须是其对齐方式的倍数，以便相同类型的对象可以在内存中相邻放置。 这就是 C/C++ 中的数组，内存中的相邻对象。 如果结构体是 int、int、char、char，那么同一个对象可能是 12 个字节，因为 char 没有对齐要求。

我说过 int 是否 4 对齐取决于平台：在 ARM 上绝对必须如此，因为未对齐的访问会引发硬件异常。 在 x86 上，您可以访问未对齐的整数，但它通常较慢并且 IIRC 非原子。 所以编译器通常（总是？）在 x86 上对整数进行 4 对齐。

如果您关心打包，那么编写代码时的经验法则是查看结构体每个成员的对齐要求。 然后对具有最大对齐类型的字段进行排序，然后是次小的，依此类推，直到没有对齐要求的成员。 例如，如果我正在尝试编写可移植代码，我可能会想到：

struct some_stuff {
    double d;   // I expect double is 64bit IEEE, it might not be
    uint64_t l; // 8 bytes, could be 8-aligned or 4-aligned, I don't know
    uint32_t i; // 4 bytes, usually 4-aligned
    int32_t j;  // same
    short s;    // usually 2 bytes, could be 2-aligned or unaligned, I don't know
    char c[4];  // array 4 chars, 4 bytes big but "never" needs 4-alignment
    char d;     // 1 byte, any alignment
};

如果您不知道字段的对齐方式，或者您正在编写可移植代码，但希望在没有重大欺骗的情况下尽最大努力，那么您假设对齐要求是结构中任何基本类型的最大要求，并且基本类型的对齐要求是它们的大小。 因此，如果您的结构体包含 uint64_t 或 long long，那么最好的猜测是它是 8 对齐的。 有时你会错，但很多时候你会是对的。

请注意，像您的博主这样的游戏程序员通常了解有关其处理器和硬件的所有信息，因此他们不必猜测。 他们知道缓存行大小，知道每种类型的大小和对齐方式，并且知道编译器使用的结构布局规则（对于 POD 和非 POD 类型）。 如果他们支持多个平台，那么他们可以根据需要对每个平台进行特殊处理。 他们还花费大量时间思考游戏中的哪些对象将受益于性能改进，并使用分析器找出真正的瓶颈所在。 但即便如此，无论对象是否需要，制定一些经验法则也不是一个坏主意。 只要不让代码变得不清楚，“将常用字段放在对象的开头”和“按对齐要求排序”是两个很好的规则。

Answer 2

根据您运行的程序的类型，此建议可能会提高性能，也可能会大大减慢速度。

在多线程程序中执行此操作意味着您将增加“错误共享”的机会。

查看 Herb Sutters 关于该主题的文章 这里

我以前已经说过了，而且我会一直这样说。 获得真正性能提升的唯一真正方法是测量代码，并使用工具来识别真正的瓶颈，而不是任意更改代码库中的内容。

Answer 3

这是优化工作集大小的方法之一。 John Robbins 有一篇很好的 文章，介绍了如何加快速度通过优化工作集大小来提高应用程序性能。 当然，它涉及仔细选择最终用户可能使用应用程序执行的最常见用例。

Answer 4

我们在这里为成员提供的指导方针略有不同（ARM 架构目标，由于各种原因，主要是 THUMB 16 位代码生成）：

• 按对齐要求分组（或者，对于新手来说，“按大小分组”通常可以解决问题）
• 最小的第一个

“按对齐分组” " 有点明显，超出了这个问题的范围； 它避免了填充，使用更少的内存等。

不过，第二个项目符号源自 THUMB LDRB（加载寄存器字节）、LDRH（加载寄存器半字）和 LDR（加载寄存器）上的小 5 位“立即”字段大小） 指示。

5 位意味着可以编码 0-31 的偏移量。 实际上，假设“this”在寄存器中很方便（通常是这样）：

• 可以将它们加载到一条指令中
• 如果 8 位字节存在于 this+0 到 this+31 16 位半字（如果存在于 this+0），则 通过这个+62；
• 32 位机器字（如果它们存在于 this+0 到 this+124）。

如果它们超出了这个范围，则必须生成多个指令：要么是带有立即数的 ADD 序列，以在寄存器中累积适当的地址，要么更糟糕的是，从函数末尾的文字池中加载。

如果我们确实访问了文字池，那就很糟糕了：文字池会通过 d-cache，而不是 i-cache； 这意味着第一次文字池访问时至少需要从主内存加载缓存行，如果文字池不在自己的缓存上启动，则数据缓存和 i-cache 之间会出现一系列潜在的逐出和失效问题行（即，如果实际代码没有在缓存行末尾结束）。

（如果我对我们正在使用的编译器有一些愿望，那么强制文字池在缓存行边界上启动的方法就是其中之一。）

（无关地，我们为避免文字池使用所做的事情之一是保留我们的所有“全局变量”都在一个表中。这意味着对“GlobalTable”进行一次文字池查找，而不是对每个全局变量进行多次查找。如果您真的很聪明，您也许可以将 GlobalTable 保存在某种内存中。无需加载文字池条目即可访问 - 是 .sbss 吗？）

Answer 5

虽然改善数据访问的缓存行为的引用局部性通常是一个相关的考虑因素，但在需要优化时控制布局还有其他几个原因 - 特别是在嵌入式系统中，即使许多嵌入式系统上使用的 CPU 甚至没有一个缓存。

- 结构中字段的内存对齐

许多程序员都很好地理解对齐注意事项，因此我不会在这里讨论太多细节。

在大多数 CPU 架构上，必须以本机对齐方式访问结构中的字段以提高效率。 这意味着，如果混合使用各种大小的字段，编译器必须在字段之间添加填充，以保持对齐要求正确。 因此，为了优化结构使用的内存，重要的是要记住这一点并布局字段，使最大的字段后面跟着较小的字段，以将所需的填充保持在最低限度。 如果要“打包”结构以防止填充，则访问未对齐字段的运行时成本很高，因为编译器必须使用对字段较小部分的一系列访问以及移位和掩码来组装字段来访问未对齐字段寄存器中的值。

- 结构中常用字段的偏移

对于许多嵌入式系统来说另一个重要的考虑因素是在结构的开头包含经常访问的字段。

某些体系结构的指令中可用于对指针访问的偏移量进行编码的位数有限，因此，如果访问偏移量超过该位数的字段，则编译器将必须使用多个指令来形成指向该字段的指针。 例如，ARM 的 Thumb 架构有 5 位来编码偏移量，因此只有当该字段距离开头的 124 字节以内时，它才能在单个指令中访问字大小的字段。 因此，如果您有一个大型结构，嵌入式工程师可能要记住的优化是将常用字段放置在结构布局的开头。

Answer 6

那么第一个成员不需要添加到指针的偏移量来访问它。

Answer 7

在 C# 中，成员的顺序由编译器确定，除非您放置属性 [LayoutKind.Sequential/Explicit]，该属性强制编译器按照您指定的方式布局结构/类。

据我所知，编译器似乎最大限度地减少了打包，同时按照自然顺序对齐数据类型（即 4 字节 int 从 4 字节地址开始）。

Answer 8

我关注的是性能、执行速度，而不是内存使用情况。
编译器在没有任何优化开关的情况下，将使用代码中声明的相同顺序来映射变量存储区域。
想象一下

 unsigned char a;
 unsigned char b;
 long c;

大混乱吗？ 没有对齐开关，低内存操作。 等人，我们将在 DDR3 dimm 上使用一个 64 位字的无符号字符，另一个使用另一个 64 位字，但这是长期不可避免的。

所以，这是每个变量的获取。

但是，打包或重新排序将导致一次提取和一次 AND 掩码能够使用无符号字符。

因此，就速度而言，在当前的 64 位字存储机器上，对齐、重新排序等都是禁忌。 我做微控制器的工作，打包/非打包的差异非常明显（谈论<10MIPS处理器，8位字存储器）

另一方面，众所周知，调整代码的性能所需的工程工作量除了一个好的算法会指导你做什么，以及编译器能够优化什么，通常会导致燃烧橡胶而没有任何实际效果。 还有一段只写的语法可疑代码。

我看到的优化的最后一步（在 uP 中，不认为这对于 PC 应用程序是可行的）是将程序编译为单个模块，让编译器对其进行优化（速度/指针分辨率/内存的更一般视图）打包等），并让链接器回收非调用的库函数、方法等。

Answer 9

理论上，如果您有大对象，它可以减少缓存未命中。 但通常最好将相同大小的成员分组在一起，这样您就有更紧密的内存包装。

Answer 10

我非常怀疑这会对 CPU 改进产生任何影响 - 也许是可读性。 如果给定帧内执行的常用基本块位于同一组页面中，则可以优化可执行代码。 这是相同的想法，但不知道如何在代码中创建基本块。 我的猜测是编译器按照它看到的顺序放置函数，而没有进行优化，因此您可以尝试将常见功能放在一起。

尝试运行分析器/优化器。 首先，使用一些分析选项进行编译，然后运行程序。 一旦分析的 exe 完成，它将转储一些分析信息。 获取此转储并将其作为输入通过优化器运行。

我已经离开这一行很多年了，但他们的工作方式并没有太大改变。