在小型结构的末尾而不是在两个成员之间使用对齐填充对性能更好吗？

问题描述

我们知道C中的某些结构中存在填充。请考虑以下2：

struct node1 {
      int a;
      int b;
      char c;
};

struct node2 {
      int a;
      char c;
      int b;
};

假设sizeof(int) = alignof(int) = 4个字节：
sizeof(node1) = sizeof(node2) = 12 ，由于填充。

两者之间的性能差异是什么？（如果有的话，将是编译器或系统架构，尤其是使用GCC）

解决方法

这些都是不好的例子-在这种情况下没关系，因为两种情况下的填充量都相同。不会有任何性能差异。

编译器将始终努力在UploaedFile的末尾填充尾随填充，否则将无法使用结构数组，因为第一个成员应始终对齐。如果不是为了某些项目struct中的尾随填充，那么struct_array[0]中的第一个成员将最终未对齐。

---

尽管如此，顺序很重要：

struct_array[1]

假设4个字节struct node3 { int a; char b; int c; char d; }; 和4个字节对齐，则int在这里占用1 + 3个字节，而b则另外占用1 + 3个字节。如果将两个d成员相邻放置，则可以写得更好，在这种情况下，填充的总量仅为2个字节。

,

如果采访者的观点基于将来扩展结构时的向后兼容性的旧观点，我不会感到惊讶。其他字段（char，smallint）可能会受益于尾随填充所占用的空间，而不会影响现有字段的内存偏移。

在大多数情况下，这是有争议的。该方法本身可能会破坏兼容性，原因有两个：

1. 在新的对齐边界上开始扩展名（就像node2那样）可能不是内存最佳的，但是它可以很好地防止新字段被'legacy'结构的填充意外覆盖。 。
2. 如果兼容性是一个主要问题（例如，当持久化或传输数据时），那么序列化/反序列化（即使是二进制）是有意义的，而不是依赖于随体系结构而变化的二进制格式。编译器，甚至每个编译器选项都可以。

,

好的，我在这里可能完全不合时宜，因为这有点超出我的联盟了。如果是这样，请纠正我。但这是我的看法：

首先，为什么我们完全需要填充和对齐？只是浪费了字节，不是吗？好吧，事实证明像这样的处理器。也就是说，如果您向运行32位整数的CPU发出指令，则CPU将要求该整数位于4的可分割内存地址中。对于64位整数，它将需要驻留在可被8整除的地址中。依此类推。这样做是为了使CPU设计更简单，性能更好。

如果您违反此要求（也称为“未对齐的内存访问”），则大多数CPU都会引发异常。 x86实际上是一个奇怪的事物，因为它仍然会执行操作-但是它将花费两倍以上的时间，因为它将以两次通过而不是一次从内存中获取值，然后通过按位魔术将这些单独的访问中的值粘贴在一起

因此，这就是编译器向结构中添加填充的原因-以便正确对齐所有成员，并且CPU可以快速（或完全访问）它们。好吧，这是假设结构本身位于适当的内存地址。但是，只要您遵循标准的分配内存操作，它也将为您提供帮助。

但是可以明确告诉编译器您也想要其他对齐方式。例如，如果要使用结构从紧密打包的文件中读取大量数据，则可以将填充明确设置为1。在这种情况下，编译器还必须发出额外的指令以补偿潜在的未对齐情况。

TL; DR-错误的对齐会使所有操作变慢（或在某些情况下可能会导致程序完全崩溃）。

但是，这不能回答“哪里可以更好地填充填充物？”的问题。需要填充，是的，但是在哪里？嗯，这并没有直接的区别，但是，通过仔细地重新排列成员，您可以减小整个结构的大小。使用更少的内存通常意味着程序更快。尤其是如果您创建这些结构的大型数组，则使用更少的内存将意味着更少的内存访问和更有效地使用CPU缓存。

但是在您的示例中，我认为没有任何区别。

P.S。为什么您的结构 end 带有填充？因为数组。编译器希望确保，如果您分配这些结构的数组，它们将全部正确对齐。因为数组成员之间没有任何填充。

,

两者之间的性能差异是什么？

性能差异“无法确定”。在大多数情况下，它没有任何区别。

对于确实有所作为的情况；两种版本都可能更快，具体取决于结构的使用方式。例如，如果您有大量此类结构的数组，并经常“随机”选择数组中的结构；那么如果您仅访问随机选择的结构的a和b，则第一个版本可能会更快（因为a和b更有可能位于同一缓存行中），并且如果您仅访问a和c，则第二个版本可能会更快。