代码对齐会显着影响性能 [英] Code alignment dramatically affects performance
问题描述
今天我发现示例代码在添加了一些不相关的代码后速度降低了 50%.调试后我发现问题出在循环对齐上.根据循环代码放置的不同，执行时间也不同，例如:
Today I have found sample code which slowed down by 50%, after adding some unrelated code. After debugging I have figured out the problem was in the loop alignment. Depending of the loop code placement there is different execution time e.g.:
| 地址 | 时间[我们] |
|---|---|
| 00007FF780A01270 | 980us |
| 00007FF7750B1280 | 1500us |
| 00007FF7750B1290 | 986us |
| 00007FF7750B12A0 | 1500us |
我之前没想到代码对齐会产生这么大的影响.而且我认为我的编译器足够聪明，可以正确对齐代码.
I didn't expect previously that code alignment may have such a big impact. And I thought my compiler is smart enough to align the code correctly.
究竟是什么导致了如此大的执行时间差异?(我想有一些处理器架构细节).
What exactly cause such a big difference in execution time ? (I suppose some processor architecture details).
我用Visual Studio 2019在Release模式下编译的测试程序，在Windows 10上运行.我已经在 2 个处理器上检查了程序:i7-8700k(上面的结果)和 intel i5-3570k，但那里不存在问题，执行时间总是大约 1250us.我也试过用 clang 编译程序，但结果总是 ~1500us(在 i7-8700k 上).
The test program I have compiled in Release mode with Visual Studio 2019 and run it on Windows 10. I have checked the program on 2 processors: i7-8700k (the results above), and on intel i5-3570k but the problem does not exist there and the execution time is always about 1250us. I have also tried to compile the program with clang, but with clang the result is always ~1500us (on i7-8700k).
我的测试程序:
#include <chrono>
#include <iostream>
#include <intrin.h>
using namespace std;
template<int N>
__forceinline void noops()
{
__nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop(); __nop();
noops<N - 1>();
}
template<>
__forceinline void noops<0>(){}
template<int OFFSET>
__declspec(noinline) void SumHorizontalLine(const unsigned char* __restrict src, int width, int a, unsigned short* __restrict dst)
{
unsigned short sum = 0;
const unsigned char* srcP1 = src - a - 1;
const unsigned char* srcP2 = src + a;
//some dummy loop,just a few iterations
for (int i = 0; i < a; ++i)
dst[i] = src[i] / (double)dst[i];
noops<OFFSET>();
//the important loop
for (int x = a + 1; x < width - a; x++)
{
unsigned char v1 = srcP1[x];
unsigned char v2 = srcP2[x];
sum -= v1;
sum += v2;
dst[x] = sum;
}
}
template<int OFFSET>
void RunTest(unsigned char* __restrict src, int width, int a, unsigned short* __restrict dst)
{
double minTime = 99999999;
for(int i = 0; i < 20; ++i)
{
auto start = chrono::steady_clock::now();
for (int i = 0; i < 1024; ++i)
{
SumHorizontalLine<OFFSET>(src, width, a, dst);
}
auto end = chrono::steady_clock::now();
auto us = chrono::duration_cast<chrono::microseconds>(end - start).count();
if (us < minTime)
{
minTime = us;
}
}
cout << OFFSET << " : " << minTime << " us" << endl;
}
int main()
{
const int width = 2048;
const int x = 3;
unsigned char* src = new unsigned char[width * 5];
unsigned short* dst = new unsigned short[width];
memset(src, 0, sizeof(unsigned char) * width);
memset(dst, 0, sizeof(unsigned short) * width);
while(true)
RunTest<1>(src, width, x, dst);
}
要验证不同的对齐方式，只需重新编译程序并更改 RunTest<0>;运行测试<1>等等.编译器总是将代码对齐到 16 字节.在我的测试代码中，我只是插入了额外的 nops 来移动代码.
To verify different alignment, just recompile the program and change RunTest<0> to RunTest<1> etc. Compiler always align the code to 16bytes. In my test code I just insert additional nops to move the code a bit more.
为 OFFSET=1 的循环生成的汇编代码(对于其他偏移，只有 npad 的数量不同):
Assembly code generated for the loop with OFFSET=1 (for other offset only the amount of npads is different):
0007c 90 npad 1
0007d 90 npad 1
0007e 49 83 c1 08 add r9, 8
00082 90 npad 1
00083 90 npad 1
00084 90 npad 1
00085 90 npad 1
00086 90 npad 1
00087 90 npad 1
00088 90 npad 1
00089 90 npad 1
0008a 90 npad 1
0008b 90 npad 1
0008c 90 npad 1
0008d 90 npad 1
0008e 90 npad 1
0008f 90 npad 1
$LL15@SumHorizon:
; 25 :
; 26 : noops<OFFSET>();
; 27 :
; 28 : for (int x = a + 1; x < width - a; x++)
; 29 : {
; 30 : unsigned char v1 = srcP1[x];
; 31 : unsigned char v2 = srcP2[x];
; 32 : sum -= v1;
00090 0f b6 42 f9 movzx eax, BYTE PTR [rdx-7]
00094 4d 8d 49 02 lea r9, QWORD PTR [r9+2]
; 33 : sum += v2;
00098 0f b6 0a movzx ecx, BYTE PTR [rdx]
0009b 48 8d 52 01 lea rdx, QWORD PTR [rdx+1]
0009f 66 2b c8 sub cx, ax
000a2 66 44 03 c1 add r8w, cx
; 34 : dst[x] = sum;
000a6 66 45 89 41 fe mov WORD PTR [r9-2], r8w
000ab 49 83 ea 01 sub r10, 1
000af 75 df jne SHORT $LL15@SumHorizon
; 35 : }
; 36 :
; 37 : }
000b1 c3 ret 0
??$SumHorizontalLine@$00@@YAXPEIBEHHPEIAG@Z ENDP ; SumHorizont
推荐答案
在慢速情况下(即 00007FF7750B1280 和 00007FF7750B12A0)，jne 指令跨越 32 字节边界.跳转条件代码"的缓解措施如下:(JCC) 勘误表(https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf) 防止此类指令被缓存在DSB.JCC 勘误仅适用于基于 Skylake 的 CPU，这就是为什么在 i5-3570k CPU 上不会出现此影响的原因.
In the slow cases (i.e., 00007FF7750B1280 and 00007FF7750B12A0), the jne instruction crosses a 32-byte boundary. The mitigations for the "Jump Conditional Code" (JCC) erratum (https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf) prevent such instructions from being cached in the DSB. The JCC erratum only applies to Skylake-based CPUs, which is why the effect does not occur on your i5-3570k CPU.
正如 Peter Cordes 在评论中指出的那样，最近的编译器提供了尝试减轻这种影响的选项.英特尔 JCC 勘误表 - JCC 真的应该单独处理吗? 提到了 MSVC 的 /QIntel-jcc-erratum选项;另一个相关问题是如何减轻英特尔 jcc 勘误对 gcc 的影响?
As Peter Cordes pointed out in a comment, recent compilers have options that try to mitigate this effect. Intel JCC Erratum - should JCC really be treated separately? mentions MSVC's /QIntel-jcc-erratum option; another related question is How can I mitigate the impact of the Intel jcc erratum on gcc?
这篇关于代码对齐会显着影响性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
