代码对齐方式会极大地影响性能。

8

今天,我发现一个示例代码在添加了一些无关代码后变慢了50%。通过调试,我发现问题出在循环对齐上。

根据循环代码的放置位置,执行时间有所不同,例如:

地址 时间[us]
00007FF780A01270 980微秒
00007FF7750B1280 1500微秒
00007FF7750B1290 986微秒
00007FF7750B12A0 1500微秒

我之前没有想到代码对齐可能会有如此大的影响。而且我认为我的编译器足够聪明,能够正确地对齐代码。

是什么原因导致执行时间有如此大的差异?(我猜测涉及一些处理器架构的细节。)

我在 Windows 10 上以 Visual Studio 2019 的 Release 模式编译并运行测试程序。

我已经在两个处理器上检查了该程序:i7-8700k(上面的结果)和 intel i5-3570k,但在那里没有这个问题,执行时间总是约为 1250 微秒。

我还尝试使用 clang 编译程序,但在 i7-8700k 上的结果始终为约 1500 微秒。

我的测试程序:

#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> 更改为 RunTest<1> 等。

编译器总是将代码对齐到16字节。在我的测试代码中,我只是插入了额外的 nops 来使代码稍微移动一些。

使用 OFFSET=1 循环生成的汇编代码(对于其他偏移量,npads 的数量不同):

  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

1
编译器选项?优化级别? - 463035818_is_not_a_number
@largest_prime_is_463035818 默认发布,x64,/O2。 - AdamF
计时器滴答的分辨率?chrono提供纳秒级别,但除非您拥有真正酷炫的定制硬件,否则您将无法达到微秒级别。在传统桌面硬件上,您甚至可能无法获得可靠的毫秒级别。 - user4581301
硬件破坏干扰尺寸是真实的。请使用它。话说,你只使用了一个编译器进行测试吗?即使是针对相同的目标架构,g++clang++MSVC 通常也会展现出非常不同的性能。 - Ted Lyngmo
对齐肯定会影响性能,这并不奇怪。编译器没有理由试图避免这种情况。通过对齐数据或函数的开头,可以确保它而不是避免它。x86有很多开销,尽管大部分这些对齐问题应该被淹没在噪音中。所以你挑出了一个有趣的问题。开始使用汇编进行测试,这样你就可以轻松控制地址/偏移量,同样要确保这不是常见的时间问题(实际上没有测量到你认为的东西)。 - old_timer
显示剩余4条评论
2个回答

11
在慢速情况下(即00007FF7750B1280和00007FF7750B12A0),jne指令会跨越32字节的边界。对于“Jump Conditional Code”(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?

3
据我所知,现代GCC/clang甚至as本身都有选项来尝试缓解这种情况。但这只是最近的效果,因此只有最新版本的编译器才知道它。相关:英特尔JCC勘误 - 是否真的应该单独处理JCC?提到了MSVC的/QIntel-jcc-erratum选项。(并指出即使勘误仅涉及JCC,缓解措施也肯定会导致JMP/CALL/RET出现问题。) - Peter Cordes
@PeterCordes 那个评论似乎太重要了,不能只留在评论中。如果Andreas同意,请将其放入答案中。 - Ted Lyngmo
1
谢谢,这正是我的问题。我还验证了/QIntel-jcc-erratum标志,并解决了问题。@Andreas Abel的答案对我来说很好,而从@Peter Cordes那里阅读详细的解释总是一种享受。 - AdamF
1
@AdamF:看起来clang创建了一个长度为3个周期的循环依赖链(加/减和一个movzx edi,di,这是无意义的:EDI的高字节并不重要)。也就是说,clang会朴素地编译它,按照原样编译,而不是使用减法作为循环依赖链的一部分,即sum += (v2-v1)。MSVC确实进行了这种优化。相关:C#中的乱序执行,关于用关联整数数学最小化延迟。编译器在非循环函数方面表现出奇差无比,但你希望clang在循环中能做得更好。 - Peter Cordes
@AdamF:你可以通过使用“unsigned int sum”来手动控制clang,这样它就不会认为需要在循环内部重新进行零扩展,而是只需存储其低16位。这就是我一开始写代码时的做法;不要引诱编译器使用不方便的大小。(另外,请注意,C++运算符如“+”会将窄参数提升为“int”,因此“sum -= v1”实际上将两侧提升为int,然后转换为“unsigned short”,在抽象机器中。)另一方面,使用较窄的类型有时可以帮助自动向量化不过度扩展,但这里没有自动向量化 :/ - Peter Cordes
显示剩余2条评论

0
我曾以为我的编译器足够聪明,可以正确地对齐代码。
正如你所说,编译器总是将东西对齐到16字节的倍数。这可能解释了对齐的直接影响。但是编译器的“智能”也有限制。
除了对齐之外,代码放置还会间接影响性能,因为缓存关联性。如果在此地址上映射的少数缓存行存在过多争用,性能将受到影响。移动到争用较少的地址可以解决问题。
编译器可能也足够聪明,可以处理缓存争用效应,但只有在启用基于配置文件的优化时才能实现。交互作用过于复杂,无法在合理的工作量内进行预测;通过实际运行程序来观察缓存冲突要容易得多,这就是PGO的作用。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接