MurmurHash3的SSE/AVX实现不一定更快，因单key场景下标量版仅需12–15条无分支指令，而向量化引入shuffle、跨lane依赖和对齐开销；仅批量处理≥8个同长对齐key时AVX2才有收益。
为什么 MurmurHash3 的 SSE/AVX 实现不一定更快
在 64 位输入或短键场景下，MurmurHash3_x64_128 的纯标量版本往往比 SSE/AVX 并行版本更快——因为现代 CPU 的乱序执行和寄存器重命名已足够高效，而向量化引入的 shuffle、permute、跨 lane 操作反而增加延迟。AVX2 版本仅在批量处理大量同长 key（如 16 字节对齐的 UUID 数组）时才有明确收益。
- 单 key 哈希：优先用标量
MurmurHash3_x64_128，它仅需约 12–15 条指令，无分支、全寄存器操作 - 批量哈希（≥ 8 个 16B key）：才值得展开为 AVX2，用
_mm256_loadu_si256+_mm256_shuffle_epi8对齐字节序，再用_mm256_mul_epu32并行混洗 - 注意
_mm256_shuffle_epi8的控制向量必须是常量（编译期确定），动态构造会导致 fallback 到标量路径
AVX2 实现中容易被忽略的字节序与对齐陷阱
x86 是小端序，但 MurmurHash3 内部按 32 位块做 rotl32 和乘法，AVX2 加载后若直接用 _mm256_loadu_si256 读 16 字节 key，低地址字节会落在寄存器低字节位置——这本身正确；但若后续用 _mm256_shuffle_epi8 做字节重排（比如模拟 le32 load），控制向量写错一位就会让整个 hash 值错乱，且难以调试。
- 验证方式：用已知输入（如
"hello"）跑标量版和 AVX2 版，对比输出的 128 位结果（推荐用printf("%016lx%016lx", h1, h2)） - 必须确保所有
_mm256_loadu_si256地址满足 16 字节对齐（否则性能暴跌），可用alignas(16)修饰 key 缓冲区 - AVX2 的
_mm256_cvtepu8_epi32等扩展指令不适用于 MurmurHash3——它不需要类型转换，强行用反而破坏原始字节流
如何安全地把 MurmurHash3 标量逻辑映射到 AVX2
核心不是“向量化整个算法”，而是识别出可并行的独立子计算：对 N 组 16 字节输入，分别执行相同的 4 步混洗（mix 1/2/3/4），每步内各 lane 完全独立。MurmurHash3_x64_128 的 mix 过程本质是 4 个 32 位整数的位运算+乘法，正好映射到 AVX2 的 8×32bit lane。
- 第一步：用
_mm256_loadu_si256加载 16B×2 组 key → 得到两个__m256i，再用_mm256_unpacklo_epi8拆成低位 8 字节和高位 8 字节 - 第二步：对每个 8 字节块调用
_mm256_mul_epu32（需先用_mm256_shuffle_epi32把低 32 位对齐到 lane 0/2） - 第三步：所有
rotl替换为_mm256_rotli_epi32（AVX2 intrinsic），避免用_mm256_sllv_epi32引入变量移位开销 - 关键约束：AVX2 版本输出仍是 128 位，但必须保证高 64 位 = 标量版
h1，低 64 位 = 标量版h2，否则无法替换现有哈希表接口
源码里最常出错的 AVX2 初始化与运行时检测
直接调用 _mm256_* 函数前未检查 CPU 是否支持 AVX2，会导致非法指令崩溃（SIGILL）。MurmurHash3 官方源码不包含运行时 dispatch，必须自行封装。
立即学习“C++免费学习笔记（深入）”；
- 检测方式：用
__builtin_cpu_supports("avx2")（GCC/Clang）或__cpuid查 ECX bit 5 - 不要在全局作用域调用 AVX2 指令——某些系统启动时 XCR0 未启用 AVX，首次使用前需执行
_mm256_zeroupper()防止影响 SSE 寄存器 - 混合编译时，确保所有用到 AVX2 的 .cpp 文件都加
-mavx2 -mbmi，且链接时不被 LTO 优化掉 dispatch 分支 - 示例 dispatch 结构：
if (__builtin_cpu_supports("avx2")) { return murmur3_avx2_batch(keys, n); } else { return murmur3_scalar_batch(keys, n); }
