看看这段代码：
一.cpp：
bool test(int a, int b, int c, int d);
int main() {
volatile int va = 1;
volatile int vb = 2;
volatile int vc = 3;
volatile int vd = 4;
int a = va;
int b = vb;
int c = vc;
int d = vd;
int s = 0;
__asm__("nop"); __asm__("nop"); __asm__("nop"); __asm__("nop");
__asm__("nop"); __asm__("nop"); __asm__("nop"); __asm__("nop");
__asm__("nop"); __asm__("nop"); __asm__("nop"); __asm__("nop");
__asm__("nop"); __asm__("nop"); __asm__("nop"); __asm__("nop");
for (int i=0; i<2000000000; i++) {
s += test(a, b, c, d);
}
return s;
}
二.cpp：
bool test(int a, int b, int c, int d) {
// return a == d || b == d || c == d;
return false;
}
一.cpp有 16 个nop。您可以注释/取消注释它们以更改循环入口点在 16 和 32 之间的对齐方式。我已经用g++ one.cpp two.cpp -O3 -mtune=native编译了它们。
以下是我的问题：
- 32 对齐版本比 16 对齐版本更快。在桑迪桥上，差异为 20%;在哈斯韦尔，8%。为什么会有差异？
- 使用 32 对齐的版本，代码在 Sandy Bridge 上运行相同的速度，哪个 return 语句是两个并不重要.cpp。我认为
return false版本至少应该快一点。但是不，完全相同的速度！ - 如果我从 one.cpp 中删除
volatile，代码会变慢(Haswell：之前：~2.17 秒，之后：~2.38 秒)。为什么？但这只有在循环对齐到 32 时才会发生。
32对齐版本更快的事实对我来说很奇怪，因为英特尔® 64 和 IA-32 架构 优化参考手册说(第3-9页)：
汇编/编译器编码规则 12.(M冲击，H一般性)所有分行 目标应为 16 字节对齐。
另一个小问题：有什么技巧可以让这个循环只对齐 32 对齐(所以其余代码可以继续使用 16 字节对齐)？
注意：我尝试了编译器 gcc 6、gcc 7 和 clang 3.9，结果相同。
这是易失性的代码(16/32 对齐的代码相同，只是地址不同)：
0000000000000560 <main>:
560: 41 57 push r15
562: 41 56 push r14
564: 41 55 push r13
566: 41 54 push r12
568: 55 push rbp
569: 31 ed xor ebp,ebp
56b: 53 push rbx
56c: bb 00 94 35 77 mov ebx,0x77359400
571: 48 83 ec 18 sub rsp,0x18
575: c7 04 24 01 00 00 00 mov DWORD PTR [rsp],0x1
57c: c7 44 24 04 02 00 00 mov DWORD PTR [rsp+0x4],0x2
583: 00
584: c7 44 24 08 03 00 00 mov DWORD PTR [rsp+0x8],0x3
58b: 00
58c: c7 44 24 0c 04 00 00 mov DWORD PTR [rsp+0xc],0x4
593: 00
594: 44 8b 3c 24 mov r15d,DWORD PTR [rsp]
598: 44 8b 74 24 04 mov r14d,DWORD PTR [rsp+0x4]
59d: 44 8b 6c 24 08 mov r13d,DWORD PTR [rsp+0x8]
5a2: 44 8b 64 24 0c mov r12d,DWORD PTR [rsp+0xc]
5a7: 0f 1f 44 00 00 nop DWORD PTR [rax+rax*1+0x0]
5ac: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0]
5b3: 00 00 00
5b6: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0]
5bd: 00 00 00
5c0: 44 89 e1 mov ecx,r12d
5c3: 44 89 ea mov edx,r13d
5c6: 44 89 f6 mov esi,r14d
5c9: 44 89 ff mov edi,r15d
5cc: e8 4f 01 00 00 call 720 <test(int, int, int, int)>
5d1: 0f b6 c0 movzx eax,al
5d4: 01 c5 add ebp,eax
5d6: 83 eb 01 sub ebx,0x1
5d9: 75 e5 jne 5c0 <main+0x60>
5db: 48 83 c4 18 add rsp,0x18
5df: 89 e8 mov eax,ebp
5e1: 5b pop rbx
5e2: 5d pop rbp
5e3: 41 5c pop r12
5e5: 41 5d pop r13
5e7: 41 5e pop r14
5e9: 41 5f pop r15
5eb: c3 ret
5ec: 0f 1f 40 00 nop DWORD PTR [rax+0x0]
无挥发性：
0000000000000560 <main>:
560: 55 push rbp
561: 31 ed xor ebp,ebp
563: 53 push rbx
564: bb 00 94 35 77 mov ebx,0x77359400
569: 48 83 ec 08 sub rsp,0x8
56d: 66 0f 1f 84 00 00 00 nop WORD PTR [rax+rax*1+0x0]
574: 00 00
576: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0]
57d: 00 00 00
580: b9 04 00 00 00 mov ecx,0x4
585: ba 03 00 00 00 mov edx,0x3
58a: be 02 00 00 00 mov esi,0x2
58f: bf 01 00 00 00 mov edi,0x1
594: e8 47 01 00 00 call 6e0 <test(int, int, int, int)>
599: 0f b6 c0 movzx eax,al
59c: 01 c5 add ebp,eax
59e: 83 eb 01 sub ebx,0x1
5a1: 75 dd jne 580 <main+0x20>
5a3: 48 83 c4 08 add rsp,0x8
5a7: 89 e8 mov eax,ebp
5a9: 5b pop rbx
5aa: 5d pop rbp
5ab: c3 ret
5ac: 0f 1f 40 00 nop DWORD PTR [rax+0x0]
这没有回答第 2 点(return a == d || b == d || c == d;与return false相同的速度)。 这仍然是一个可能有趣的问题，因为它必须编译多个到 uop 缓存的指令行。
32对齐版本更快这一事实对我来说很奇怪，因为[英特尔的手册说要对齐16]
优化指南建议是一个非常通用的指导方针，绝对并不意味着更大的永远不会有帮助。 通常不会，填充到 32 更有可能伤害而不是帮助。 (I缓存未命中、ITLB未命中以及从磁盘加载的更多代码字节)。
事实上，很少需要 16B 对齐，尤其是在具有 uop 缓存的 CPU 上。 对于可以从循环缓冲区运行的小循环，它的对齐通常完全无关紧要。
(Skylake 微码更新禁用了循环缓冲区，以解决部分寄存器 AH 合并错误 SKL150。 这为跨越 32 字节边界的微小循环带来了问题，每 2 个时钟只运行一次迭代，而不是你可能从 Haswell 上的 6 uop 循环中获得的每 1.5 次迭代，或者在具有较旧微码的 SKL 上。 LSD直到Ice Lake才重新启用，在Kaby/Coffee/Comet Lake中被打破，这与SKL/SKX的微架构相同。
另一个 SKL 勘误表解决方法造成了另一个更糟糕的代码对齐坑：如何减轻英特尔 JCC 勘误表对 gcc 的影响？
16B 作为一个广泛的建议仍然不错，但它并没有告诉您了解几个特定 CPU 上的特定情况所需的一切。
编译器通常默认对齐循环分支和函数入口点，但通常不对齐其他分支目标。 执行 NOP(和代码膨胀)的成本通常大于未对齐的非循环分支目标的可能成本。
代码对齐有一些直接和间接的影响。 直接影响包括英特尔 SnB 家族上的 uop 高速缓存。 例如，请参阅 涉及英特尔 SnB 家族 CPU 上的微编码指令的循环的分支对齐。
英特尔优化手册的另一部分详细介绍了 uop 缓存的工作原理：
2.3.2.2 解码芯片：
- 所有微操作方式(uop 缓存行)表示在代码中静态连续的指令，并且其 EIP 位于 相同对齐的 32 字节区域。 (我认为这意味着一个指令 超出边界进入块的 UOP 缓存包含其开始，而不是结束。 跨越指令必须 去某个地方，分支目标地址将运行 指令是INSN的开始，所以把它放在 该块的行)。
- 多微操作指令不能跨方式拆分。
- 打开 MSROM 的指令会消耗整个方式。
- 单程最多允许两个分支。
- 一对宏融合指令保留为一个微操作。
另请参阅Agner Fog的微拱指南。 他补充说：
- 无条件跳转或调用总是结束 μop 缓存行
- 许多其他可能与这里无关的东西。
此外，如果您的代码不适合 uop 缓存，则无法从循环缓冲区运行。
对齐的间接影响包括：
- 更大/更小的代码大小(L1I 缓存未命中，TLB)。 与您的测试无关
- 哪些分支在 BTB(分支目标缓冲区)中相互别名。
如果我从 .cpp 中删除
volatiles，代码会变慢。为什么？
较大的指令将最后一条指令推入跨越 32B 边界的循环中：
59e: 83 eb 01 sub ebx,0x1
5a1: 75 dd jne 580 <main+0x20>
因此，如果您不是从循环缓冲区 (LSD) 运行，那么如果没有volatile一个 uop 缓存提取周期，则只会获得 1 uop。
如果子/jne 宏融合，这可能不适用。 我认为只有越过64B的边界才能打破宏观融合。
此外，这些不是真实地址。 您是否检查过链接后的地址是什么？ 如果文本部分的对齐方式少于 64B，则链接后可能存在 64B 边界。
同样与 32 字节边界相关，JCC 勘误表在 Skylake CPU 上禁用分支(包括宏融合的 ALU+JCC)包含行的最后一个字节的块的 uop 缓存。如何减轻英特尔 JCC 勘误表对 gcc 的影响？
抱歉，我实际上还没有对此进行测试以了解有关此特定案例的更多信息。 关键是，当你在前端遇到瓶颈时，比如在紧密循环中有一个call/ret，对齐变得很重要，并且可以变得非常复杂。 所有未来指令的边界交叉或不跨越都会受到影响。 不要指望它很简单。 如果你读过我的其他答案，你就会知道我通常不是那种说"这太复杂而无法完全解释"的人，但对齐可以是这样。
另请参阅一个对象文件中的代码对齐正在影响另一个对象文件中函数的性能
在您的情况下，请确保内联微小的函数。如果您的代码库在单独的.c文件中而不是在可以内联的.h中具有任何重要的微小函数，请使用链接时优化。或者更改您的代码以将它们放在.h中。