了解较长代码执行速度提高 4 倍的微架构原因AMD Zen 2 架构

编程问答 2022-05-23

问题描述

我在 x64 模式下使用 VS 2019（版本 16.8.6）编译了以下 C++17 代码：

struct __declspec(align(16)) Vec2f { float v[2]; };
struct __declspec(align(16)) Vec4f { float v[4]; };

static constexpr std::uint64_t N = 100'000'000ull;

const Vec2f p{};
Vec4f acc{};

// Using virtual method:
for (std::uint64_t i = 0; i < N; ++i)
    acc += foo->eval(p);

// Using function pointer:
for (std::uint64_t i = 0; i < N; ++i)
    acc += eval_fn(p);

在第一个循环中，foo 是一个 std::shared_ptr，而 eval() 是一个虚方法：

__declspec(noinline) virtual Vec4f eval(const Vec2f& p) const noexcept
{
    return { p.v[0],p.v[1],p.v[0],p.v[1] };
}

在第二个循环中，eval_fn 是指向以下函数的指针：

__declspec(noinline) Vec4f eval_fn_impl(const Vec2f& p) noexcept
{
    return { p.v[0],p.v[1] };
}

最后，我有 operator+= 的两个 Vec4f 实现：

  • 一个使用显式循环实现的：

    Vec4f& operator+=(Vec4f& lhs,const Vec4f& rhs) noexcept
{
    for (std::uint32_t i = 0; i < 4; ++i)
        lhs.v[i] += rhs.v[i];
    return lhs;
}

  • 还有一个用 SSE 内在实现：

    Vec4f& operator+=(Vec4f& lhs,const Vec4f& rhs) noexcept
{
    _mm_store_ps(lhs.v,_mm_add_ps(_mm_load_ps(lhs.v),_mm_load_ps(rhs.v)));
    return lhs;
}

您可以在下面找到测试的完整（独立，仅限 Windows）代码。

以下是两个循环的生成代码，以及在 AMD Threadripper 3970X cpu（Zen 2 架构）上执行时以毫秒为单位的运行时间（对于 100M 迭代）：

  • 使用operator+=(Vec4f&,const Vec4f&)的SSE内在实现：

    // Using virtual method: 649 ms
$LL4@main:
  mov rax,QWORD PTR [rdi]            // fetch vtable base pointer (rdi = foo)
  lea r8,QWORD PTR p$[rsp]           // r8 = &p
  lea rdx,QWORD PTR $T3[rsp]         // not sure what $T3 is (some kind of temporary,but why?)
  mov rcx,rdi                        // rcx = this
  call    QWORD PTR [rax]             // foo->eval(p)
  addps   xmm6,XMMWORD PTR [rax]
  sub rbp,1
  jne SHORT $LL4@main

// Using function pointer: 602 ms
$LL7@main:
  lea rdx,QWORD PTR p$[rsp]          // rdx = &p
  lea rcx,QWORD PTR $T2[rsp]         // same question as above
  call    rbx                         // eval_fn(p)
  addps   xmm6,XMMWORD PTR [rax]
  sub rsi,1
  jne SHORT $LL7@main

  • 使用operator+=(Vec4f&,const Vec4f&)的显式循环实现：

    // Using virtual method: 167 ms [3.5x to 4x FASTER!]
$LL4@main:
  mov rax,QWORD PTR [rdi]
  lea r8,QWORD PTR p$[rsp]
  lea rdx,QWORD PTR $T5[rsp]
  mov rcx,rdi
  call    QWORD PTR [rax]
  addss   xmm9,DWORD PTR [rax]
  addss   xmm8,DWORD PTR [rax+4]
  addss   xmm7,DWORD PTR [rax+8]
  addss   xmm6,DWORD PTR [rax+12]
  sub rbp,1
  jne SHORT $LL4@main

// Using function pointer: 600 ms
$LL7@main:
  lea rdx,QWORD PTR p$[rsp]
  lea rcx,QWORD PTR $T4[rsp]
  call    rbx
  addps   xmm6,1
  jne SHORT $LL7@main

（在 AMD Zen 2 arch 上，据我所知，addss 和 addps 指令有 3 个周期的延迟，最多可以同时执行两条这样的指令。）

>

让我感到困惑的情况是使用虚拟方法和 operator+= 的显式循环实现：

为什么它比其他三种变体快 3.5 到 4 倍？

这里有哪些相关的建筑效果？在循环的后续迭代中寄存器之间的依赖性更少？或者在缓存方面运气不好？

完整源代码：

#include <Windows.h>
#include <cstdint>
#include <cstdio>
#include <memory>
#include <xmmintrin.h>

struct __declspec(align(16)) Vec2f
{
    float v[2];
};

struct __declspec(align(16)) Vec4f
{
    float v[4];
};

Vec4f& operator+=(Vec4f& lhs,const Vec4f& rhs) noexcept
{
#if 0
    _mm_store_ps(lhs.v,_mm_load_ps(rhs.v)));
#else
    for (std::uint32_t i = 0; i < 4; ++i)
        lhs.v[i] += rhs.v[i];
#endif
    return lhs;
}

std::uint64_t get_timer_freq()
{
    LARGE_INTEGER frequency;
    QueryPerformanceFrequency(&frequency);
    return static_cast<std::uint64_t>(frequency.QuadPart);
}

std::uint64_t read_timer()
{
    LARGE_INTEGER count;
    QueryPerformanceCounter(&count);
    return static_cast<std::uint64_t>(count.QuadPart);
}

struct Foo
{
    __declspec(noinline) virtual Vec4f eval(const Vec2f& p) const noexcept
    {
        return { p.v[0],p.v[1] };
    }
};

using SampleFn = Vec4f (*)(const Vec2f&);

__declspec(noinline) Vec4f eval_fn_impl(const Vec2f& p) noexcept
{
    return { p.v[0],p.v[1] };
}

__declspec(noinline) SampleFn make_eval_fn()
{
    return &eval_fn_impl;
}

int main()
{
    static constexpr std::uint64_t N = 100'000'000ull;

    const auto timer_freq = get_timer_freq();
    const Vec2f p{};
    Vec4f acc{};

    {
        const auto foo = std::make_shared<Foo>();
        const auto start_time = read_timer();
        for (std::uint64_t i = 0; i < N; ++i)
            acc += foo->eval(p);
        std::printf("foo->eval: %llu ms\n",1000 * (read_timer() - start_time) / timer_freq);
    }

    {
        const auto eval_fn = make_eval_fn();
        const auto start_time = read_timer();
        for (std::uint64_t i = 0; i < N; ++i)
            acc += eval_fn(p);
        std::printf("eval_fn: %llu ms\n",1000 * (read_timer() - start_time) / timer_freq);
    }

    return acc.v[0] + acc.v[1] + acc.v[2] + acc.v[3] > 0.0f ? 1 : 0;
}

解决方法

我正在 Intel Haswell 处理器上对此进行测试，但性能结果相似，我猜原因也相似，但对此持保留态度。 Haswell 和 Zen 2 之间当然存在差异，但据我所知，我所指责的效果应该适用于它们。

问题是：虚拟方法/函数调用通过指针/不管它是什么，执行 4 个标量存储，但随后主循环执行相同内存的向量加载。 Store-to-load forwarding 可以处理存储一个值然后立即加载的各种情况，但通常不是像这样一个负载依赖于多个存储的情况（更一般地说：负载依赖于仅部分提供的存储负载尝试加载的数据）。假设它可能是可能的，但它不是当前微架构的特征。

作为实验，更改虚拟方法中的代码以使用向量存储。例如：

__declspec(noinline) virtual Vec4f eval(const Vec2f& p) const noexcept
{
    Vec4f r;
    auto pv = _mm_load_ps(p.v);
    _mm_store_ps(r.v,_mm_shuffle_ps(pv,pv,_MM_SHUFFLE(1,1,0)));
    return r;
}

在我的 PC 上，它使时间与快速版本保持一致，这支持了问题是由多个标量存储输入向量负载引起的假设。

从 8 字节 Vec2f 加载 16 字节并不完全合法，如有必要，可以解决这个问题。只有 SSE(1) 有点烦人，SSE3 很适合 _mm_loaddup_pd（又名 movddup）。

如果 MSVC 通过寄存器而不是通过出指针返回 Vec4f 结果，则不会存在此问题，但除了更改返回值之外，我不知道如何说服它这样做输入 __m128。 __vectorcall 也有帮助，但使 MSVC 返回 几个寄存器 中的结构，然后在调用者中重新组合并进行额外的 shuffle。它比任何一个快速选项都有些混乱和慢，但仍然比存储转发失败的版本快。

amd-processorassemblyc++cpu-architecture