（如何）使用 LLVM 机器代码分析器预测代码片段的运行时间？

我使用 llvm-mca 来计算总周期一段代码，认为他们会预测它的运行时间。然而，动态测量运行时间几乎没有相关性。所以：为什么 llvm-mca 计算的总周期不能准确预测运行时间？我可以使用 llvm-mca 以更好的方式预测运行时间吗？

Details:

我想知道以下代码对于不同类型的运行时begin (and end) 迭代器，对于startValue being 0.0 or 0ULL:

std::accumulate(begin, end, starValue)

为了预测运行时间，我使用了编译器资源管理器（https://godbolt.org/z/5HDzSF）及其 LLVM 机器代码分析器 (llvm-mca) 插件，因为 llvm-mca 是“一种性能分析工具，它使用 LLVM 中可用的信息（例如调度模型）来静态测量性能”。我使用了以下代码：

using vec_t = std::vector<double>;

vec_t generateRandomVector(vec_t::size_type size)
{
    std::random_device rnd_device;
    std::mt19937 mersenne_engine {rnd_device()};
    std::uniform_real_distribution dist{0.0,1.1};
    auto gen = [&dist, &mersenne_engine](){
        return dist(mersenne_engine);
    };
    vec_t result(size);
    std::generate(result.begin(), result.end(), gen);
    return result;
}

double start()
{
    vec_t vec = generateRandomVector(30000000);
    vec_t::iterator vectorBegin = vec.begin();
    vec_t::iterator vectorEnd = vec.end();
    __asm volatile("# LLVM-MCA-BEGIN stopwatchedAccumulate");
    double result = std::accumulate(vectorBegin, vectorEnd, 0.0);
    __asm volatile("# LLVM-MCA-END");    
    return result;
}

但是，我发现 llvm-mca 的总周期计算机与运行相应的 std::accumulate 的挂钟时间之间没有相关性。例如，在上面的代码中，总周期为 2806，运行时间为 14ms。当我切换到 startValue 时0ULL，总周期为 2357，但运行时间为 117ms。

TL:DR: LLVM-MCA 分析了这些注释之间的整个代码块，就好像它是body一个循环，并向您显示所有这些指令 100 次迭代的循环计数。

但除了实际（微小）循环之外，大多数指令都是循环设置以及循环后的 SIMD 水平求和，实际上只运行一次。 （这就是为什么周期数是数千，而不是 400 = 100 倍的 4 周期延迟vaddpd在 Skylake 上0.0版本带有double累加器。）

如果您取消选中 Godbolt 编译器资源管理器上的“//”框，或者修改 asm 语句以添加 nop ，例如"nop # LLVM-MCA-END"，您将能够在 asm 窗口中找到这些行，并查看 LLVM-MCA 正在查看的内容，因为它是“循环”。

LLVM MCA 模拟指定的汇编指令序列并计算估计执行所需的周期数每次迭代在指定的目标架构上。 LLVM MCA 进行了许多简化，例如（我突然想到）：（1）它假设所有条件分支都失败，（2）它假设所有内存访问都是写回内存类型并且全部命中L1 缓存，(3) 假设前端工作最佳，(4)call被调用的过程中没有遵循指令，它们就会失败。还有其他假设，我目前不记得了。

本质上，LLVM MCA（如英特尔 IACA）仅适用于后端计算绑定的简单循环。在 IACA 中，虽然支持大多数指令，但仍有少数指令没有详细建模。例如，假设预取指令仅消耗微架构资源，但延迟基本上为零，并且对存储器层次结构的状态没有影响。然而，在我看来，马华完全忽视了这样的指示。无论如何，这与你的问题不是特别相关。

现在回到你的代码。在您提供的编译器资源管理器链接中，您没有将任何选项传递给 LLVM MCA。因此，默认的目标架构生效，即该工具运行的任何架构。这恰好是SKX。您提到的总周期数是针对 SKX 的，但不清楚您是否在 SKX 上运行代码。您应该使用-mcpu指定架构的选项。这独立于-march你转到了海湾合作委员会。另请注意，将核心周期与毫秒进行比较是没有意义的。您可以使用RDTSC用于测量以核心周期为单位的执行时间的指令。

请注意编译器如何内联对std::accumulate。显然，这段代码从装配线 405 开始，也是该指令的最后一条指令。std::accumulate位于第444行，共38条指令。 LLVM MCA 估计与实际性能不符的原因现在已经很清楚了。该工具假设所有这些指令都在循环中执行大量迭代。显然事实并非如此。 420-424之间只有一个循环：

.L75:
        vaddpd  ymm0, ymm0, YMMWORD PTR [rax]
        add     rax, 32
        cmp     rax, rcx
        jne     .L75

仅应将此代码输入到 MCA。在源代码级别，确实没有办法告诉 MCA 只分析这段代码。你必须手动内联std::accumulate并放置LLVM-MCA-BEGIN and LLVM-MCA-END在其内部某处进行标记。

经过时0ULL代替0.0 to std::accumulate，LLVM MCA 的输入将从汇编指令 402 开始，到 441 结束。请注意，MCA 不支持任何指令（例如vcvtsi2sdq）将在分析中完全省略。代码中实际处于循环中的部分是：

.L78:
        vxorpd  xmm0, xmm0, xmm0
        vcvtsi2sdq      xmm0, xmm0, rax
        test    rax, rax
        jns     .L75
        mov     rcx, rax
        and     eax, 1
        vxorpd  xmm0, xmm0, xmm0
        shr     rcx
        or      rcx, rax
        vcvtsi2sdq      xmm0, xmm0, rcx
        vaddsd  xmm0, xmm0, xmm0
.L75:
        vaddsd  xmm0, xmm0, QWORD PTR [rdx]
        vcomisd xmm0, xmm1
        vcvttsd2si      rax, xmm0
        jb      .L77
        vsubsd  xmm0, xmm0, xmm1
        vcvttsd2si      rax, xmm0
        xor     rax, rdi
.L77:
        add     rdx, 8
        cmp     rsi, rdx
        jne     .L78

注意这里有一个条件跳转，jns，在目标地址位于块中某处的代码中。 MCA 只会假设跳跃会失败。如果实际运行代码时情况并非如此，MCA 将不必要地增加 7 条指令的开销。还有一次跳跃，jb，但我认为这对于大向量来说并不重要，并且大多数时候都会失败。最后一跳，jne，也是最后一条指令，因此 MCA 会假设下一条指令又是最上面的指令。对于足够多的迭代次数，这个假设是完全正确的。

总的来说，很明显第一个代码比第二个代码小得多，因此它可能要快得多。您的测量确实证实了这一点。您实际上也不需要使用微架构分析工具来理解原因。第二个代码只是做了更多的计算。所以你可以很快得出结论：通过0.0在所有架构上的性能和代码大小方面都更好。