为什么64位计数器在循环中会破坏 _mm_popcnt_u64 的性能

至今仍困扰C++开发者的著名错误

2013年，Stack Overflow上出现了一个问题，获得了数十万次浏览，并在C++优化者中引发了一场真正的热潮。问题大致是：“我将循环计数器中的 int 替换为 uint64_t，性能下降了10倍。为什么？”答案并非魔法，而是源于英特尔处理器的微架构。到了2025年，这个问题依然存在：现代芯片仍然可能因为看似无害的数据类型替换而“卡顿”。

今天，我们将以 _mm_popcnt_u64 指令（计算64位字中置位位的数量）为例，剖析这个悖论，展示受此异常影响的实际代码，并给出如何在2025年编写快速且可预测的C++代码的明确建议。

问题本质：32位 vs 64位计数器

想象一个简单的循环，它计算64位整数数组中置位位（popcount）的总数。我们使用来自 SSE4.2 指令集的内建函数 _mm_popcnt_u64。以下是两种代码变体——第一种使用32位计数器，第二种使用64位计数器：

#include <cstdint>\n#include <vector>\n#include <nmmintrin.h> // 用于 _mm_popcnt_u64\n\n// 变体1：32位计数器（快速）\nuint64_t popcnt_32bit(const std::vector<uint64_t>& data) {\n    uint64_t result = 0;\n    for (int i = 0; i < data.size(); ++i) {   // int — 32位\n        result += _mm_popcnt_u64(data[i]);\n    }\n    return result;\n}\n\n// 变体2：64位计数器（慢速）\nuint64_t popcnt_64bit(const std::vector<uint64_t>& data) {\n    uint64_t result = 0;\n    for (uint64_t i = 0; i < data.size(); ++i) { // uint64_t — 64位\n        result += _mm_popcnt_u64(data[i]);\n    }\n    return result;\n}\n

如果在英特尔处理器（例如 Core i7-13700K 或更旧的 Haswell）上测量速度，差异将令人震惊：第二种变体可能慢 3 到 10 倍。而在 AMD Ryzen 上则没有这种异常——两种变体运行速度相同。

为什么会这样？根源在于虚假依赖

在英特尔处理器上（直到最新型号），POPCNT 指令存在虚假依赖（false dependency）于目标寄存器。形式上，POPCNT 会完全覆写输出寄存器，但在微架构层面，处理器的行为就好像它在写入之前读取了旧结果。这是英特尔实现中的一个错误（或特性）。

现在看看带有64位计数器 i 的循环。编译器被迫使用同一个寄存器（例如 rax）来存储计数器和 POPCNT 的中间结果。每次迭代都会创建一个依赖链：下一次 POPCNT 必须等待上一次完成才能开始，因为处理器“认为”它需要旧结果。这破坏了流水线。

使用32位计数器时，编译器会使用不同的寄存器（例如，用 ecx 作为计数器，用 rax 累加结果），因此不会产生虚假依赖——POPCNT 可以并行执行。

汇编级详细分析

为了确认这一点，让我们看看每种变体编译后的结果（GCC 13，标志 -O3 -march=native）：

32位计数器（快速）：

.L3:\n    popcnt rcx, QWORD PTR [rdx]   ; popcnt 到 rcx（独立寄存器）\n    add    rax, rcx                ; 累加到累加器\n    add    rdx, 8                  ; 指针偏移\n    cmp    rdi, rdx                ; 比较\n    jne    .L3\n

64位计数器（慢速）：

.L7:\n    popcnt rax, QWORD PTR [rdx]   ; popcnt 到 rax — 与累加器相同