__builtin_popcount比手写循环快得多，因其直接映射为CPU的POPCNT指令，单周期完成64位计数；而手写循环需至少64次分支+移位，严重阻塞流水线。
为什么 __builtin_popcount 比手写循环快得多
因为编译器直接映射到 CPU 的专用指令（如 x86 的 POPCNT），单周期完成 64 位计数，而手动遍历每位至少要 64 次分支或移位操作。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先用
__builtin_popcount（GCC/Clang）或_mm_popcnt_u64（MSVC + intrin.h），前提是目标平台支持POPCNT指令（可通过__builtin_cpu_supports("popcnt")检查） - 若需跨平台且不能依赖编译器内置，避免写
while (x) { count += x & 1; x >>= 1; }—— 它对全零输入仍要循环 64 次 - 改用“清除最低位 1”的技巧：
while (x) { count++; x &= x - 1; }，循环次数 = 实际 1 的个数，最坏仍是 64 次，但平均更优
如何在无 POPCNT 指令的旧 CPU 上保持高性能
查表法是可靠 fallback：用 256 字节的预计算表覆盖所有 uint8_t 值，再将 64 位整数拆成 8 个字节分别查表累加。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 静态表定义为
static constexpr uint8_t popcount_table[256] = {...};，确保编译期初始化、零运行时开销 - 拆字节时别用
(x >> i*8) & 0xFF—— 编译器可能生成多余移位；改用联合体或reinterpret_cast<const uint8_t>(&x)[i]</const>（注意小端序） - 对齐敏感场景（如处理大量数组），可一次加载 8 字节并用 SIMD 指令并行查表，但需 SSE4.2 或更高支持
std::popcount（C++20）能直接替代 __builtin_popcount 吗
可以，但要注意标准库实现是否真正调用硬件指令。libstdc++ 和 libc++ 在优化构建下通常会内联为 POPCNT，但 MSVC 的 std::popcount 在早期 19.3x 版本中仍为查表实现。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 启用
-march=native或-mpopcnt（GCC/Clang）确保编译器知道目标支持该指令 - 用
static_assert(std::has_single_bit(sizeof(unsigned long long)));类似方式验证类型宽度，避免传入int却期望 64 位行为 - 若需严格控制指令生成（如嵌入式或模拟环境），仍建议显式用
__builtin_popcountll处理uint64_t
批量处理时缓存友好性比单次调用更重要
连续调用 std::popcount 处理数组，不如一次读取多个值做位运算合并——比如用 SWAR（SIMD Within A Register）技术，把 8 个 uint8_t 的 popcount 并行算出。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对 uint32_t 数组，可用经典 SWAR 公式：
x = x - ((x >> 1) & 0x55555555); x = (x & 0x33333333) + ((x >> 2) & 0x33333333); ...，但注意中间结果溢出风险，需用足够宽类型暂存 - 现代做法是用
std::vector<uint64_t></uint64_t>配合_mm_popcnt_u64+ `_mm_loadu_si128` 批量加载，比逐个调用快 3–5 倍（实测于 Skylake） - 别忽略内存对齐：未对齐访问在某些 CPU 上触发额外周期，用
alignas(64)对齐缓冲区更稳妥
实际项目里最容易被忽略的是指令集运行时检测和降级路径——你以为开了 -mpopcnt 就万事大吉，但用户 CPU 可能不支持，而程序又没 fallback 到查表，直接崩在 Illegal instruction。
