代码对齐会显着影响性能

如何解决代码对齐会显着影响性能

今天我发现示例代码在添加了一些不相关的代码后速度降低了 50%。调试后我发现问题出在循环对齐上。根据循环代码放置的不同，执行时间也不同，例如：

地址	时间[我们]
00007FF780A01270	980us
00007FF7750B1280	1500us
00007FF7750B1290	986us
00007FF7750B12A0	1500us

我之前没想到代码对齐会产生这么大的影响。而且我认为我的编译器足够聪明，可以正确对齐代码。

究竟是什么导致了如此大的执行时间差异？（我想有一些处理器架构细节）。

我用Visual Studio 2019在Release模式下编译的测试程序，在Windows 10上运行。我已经在 2 个处理器上检查了程序：i7-8700k（上面的结果）和 intel i5-3570k，但那里不存在问题，执行时间总是大约 1250us。我也试过用 clang 编译程序，但结果总是 ~1500us（在 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,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,sizeof(unsigned char) * width);
    memset(dst,sizeof(unsigned short) * width);

    while(true)
    RunTest<1>(src,x,dst);
}

要验证不同的对齐方式，只需重新编译程序并将 RunTest 更改为 RunTest 等。编译器总是将代码对齐到 16 字节。在我的测试代码中，我只是插入了额外的 nops 来移动代码。

为 OFFSET=1 的循环生成的汇编代码（对于其他偏移，只有 npad 的数量不同）：

  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 上不会出现此影响的原因。

正如 Peter Cordes 在评论中指出的那样，最近的编译器提供了尝试减轻这种影响的选项。 Intel JCC Erratum - should JCC really be treated separately? 提到了 MSVC 的 /QIntel-jcc-erratum 选项；另一个相关问题是 How can I mitigate the impact of the Intel jcc erratum on gcc?

我认为我的编译器足够聪明，可以正确对齐代码。

正如您所说，编译器总是将事物对齐为 16 字节的倍数。这可能确实说明了对齐的直接影响。但是编译器的“智能”是有限度的。

除了对齐之外，由于缓存关联性，代码放置也会对性能产生间接影响。如果对可以映射到该地址的少数高速缓存行存在太多争用，性能将受到影响。转移到争用较少的地址会使问题消失。

编译器可能足够智能，可以处理缓存争用效应，但前提是您打开了配置文件引导的优化。交互过于复杂，无法在合理的工作量中进行预测；通过实际运行程序可以更容易地观察缓存冲突，而这正是 PGO 所做的。