C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

可靠。需先调用__cpuid(0x00000001)检查ECX第28位（AVX），再调用__cpuidex(0x00000007, 0)检查EBX第5位（AVX2），二者缺一不可，仅查前者会导致老Haswell平台崩溃。

用 __cpuid 和 __cpuidex 检查 AVX2 支持是否可靠？ Windows 和 Linux（x86_64）下，__cpuid 是最轻量、最直接的检测方式。但注意：仅靠 ECX 第 28 位（AVX）置位 ≠ AVX2 可用——AVX2 需要额外检查 __cpuidex(0x00000007, 0) 的 EBX 第 5 位。 常见错误是只查 cpuid.0x00000001.ECX[28] 就认为能跑 AVX2，结果在老 Haswell（有 AVX 无 AVX2）上崩溃。必须组合两步：

• 先调用 __cpuid(info, 0x00000001)，确认 info[2] & (1 为真（AVX 基础支持）
• 再调用 __cpuidex(info, 0x00000007, 0)，检查 info[1] & (1 （AVX2 标志）
• Linux 下若用内联汇编替代 intrinsic，需确保 %rax 清零后再进 cpuid，否则部分旧内核会因寄存器污染出错

AVX-512 检测为什么不能只看 ECX[16]？ cpuid.0x00000007.ECX[16]（AVX512F）只是基础指令集，实际运行还需 OS 支持 XSAVE/XRSTOR 保存 ZMM 寄存器上下文。若内核未启用 XSAVE 或禁用 AVX-512（如 Intel 的 avx512=off 内核参数），即使 CPU 硬件支持，执行 ZMM 指令也会触发 #GP(0) 异常。 实操中必须补查 OS 级就绪状态：

• Linux：读取 /proc/cpuinfo 中是否有 avx512f、avx512cd 等完整 flag（比单纯 cpuid 更可信）
• Windows：调用 IsProcessorFeaturePresent(PF_AVX512_ENABLED)（Win10 1903+），它内部已封装 OS/XSAVE 检查
• 跨平台项目建议 fallback 到 sigsetjmp + 执行一条 vpxord %zmm0,%zmm0,%zmm0 测试指令，捕获 SIGILL —— 这比纯 cpuid 更贴近真实运行环境

如何让编译器生成多版本代码并运行时分发？ GCC/Clang 支持 -march=native，但生产环境需兼容不同 CPU。推荐用函数多版本（IFUNC）或手动 dispatch：

• Clang/GCC：用 __attribute__((target("avx2"))) void kernel_avx2(...) 声明优化版，主函数内用指针切换
• 避免在循环内反复判断指令集——把检测提到初始化阶段，存为全局 bool has_avx2 或函数指针
• 注意：AVX-512 会提高功耗并可能降频，某些场景（如移动端或高密度服务）即使检测到也应允许强制禁用，通过环境变量（如 DISABLE_AVX512=1）控制
• 不要用 std::function 包装 dispatch 函数——虚调用开销抵消了向量化收益；直接用函数指针或模板特化

为什么 _mm256_loadu_ps 在 AVX512 机器上反而更慢？ AVX2 的 256-bit 指令在 AVX-512 CPU 上仍可执行，但部分微架构（如 Skylake-X）对混合宽度操作有惩罚：当 ZMM 寄存器被使用后，再执行 YMM/XMM 指令会触发“upper bits 清零”隐式开销（vzeroupper 缺失时尤其明显）。 这不是 bug，而是硬件设计权衡。解决方案很具体：

• 若确定走 AVX512 路径，全部用 _mm512_* 系列，避免混用 _mm256_*
• 若需兼容 AVX2/AVX512 共存逻辑，在 AVX2 分支末尾显式加 _mm256_zeroupper()（GCC/Clang intrinsic）
• Clang 14+ 默认对 -mavx512f 启用 -mavx2 兼容模式，但 GCC 仍需手动加 -mavx2 才生成 YMM 指令——别依赖编译器自动降级

检测本身不难，难的是把“CPU 支持”、“OS 就绪”、“编译器生成”、“运行时调度”、“微架构行为”这五层全串起来。少验一层，上线后就可能在某台机器上静默变慢，或者直接 SIGILL。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！