必须运行时检测CPU是否支持AVX（如__builtin_cpu_supports("avx")），否则在不支持的机器或Docker容器中会触发SIGILL；同时优先使用未对齐加载存储函数（_mm256_loadu_ps/_mm256_storeu_ps）并提供SSE2 fallback，确保兼容性与安全性。
直接用 _mm256_add_ps 却没检查 CPU 是否支持 AVX，程序大概率在老机器或 Docker 容器里崩溃；不处理内存对齐和尾部数据，性能可能比标量还差。手动向量化不是“加几个 intrinsic 就提速”，而是要同时控制硬件能力、内存布局和控制流。
怎么安全调用 AVX/SSE 函数而不 SIGILL
编译时启用 -mavx 只告诉编译器“允许生成 AVX 指令”，不代表运行时能执行。很多线上环境（尤其是容器、CI 节点、云服务器）CPU 不支持 AVX，或者宿主机特性未透传到容器内，_mm256_load_ps 一执行就触发 SIGILL。
- 运行时检测必须做：GCC/Clang 用
__builtin_cpu_supports("avx")，MSVC 用__cpuid查 ECX 第 28 位 - 不要只依赖
#ifdef __AVX__—— 那只是编译宏，和目标机器无关 - 最低安全基线是 SSE2：
__m128和_mm_add_ps在所有 x86-64 CPU 上都可用，可作 fallback 路径 - Docker 场景下，确认
/proc/cpuinfo中有avx标志；若无，需加--cap-add=SYS_PTRACE --security-opt seccomp=unconfined或换基础镜像
内存对齐与 load/store 函数怎么选
_mm256_load_ps 要求地址 32 字节对齐，错用会触发 Segmentation fault（Linux）或 EXC_BAD_ACCESS（macOS）。但实际业务中，std::vector<float></float> 默认不保证对齐，new float[n] 也不行。
- 安全首选：
_mm256_loadu_ps和_mm256_storeu_ps—— 支持任意地址，性能损失通常 - 真要榨干性能：用
aligned_alloc(32, size)或_mm_malloc(size, 32)分配内存，并用alignas(32)声明栈数组 - 结构体成员对齐也要同步处理：比如
struct alignas(32) Vec4 { float x,y,z,w; };，否则打包进数组仍可能错位 - NEON（ARM）对应的是
vld1q_f32/vst1q_f32，没有“u”后缀变体，必须确保对齐
数组长度不是 8 的倍数怎么办
AVX 处理 float 是 8 个一组（__m256），但输入长度 n 几乎从不整除 8。常见错误是循环末尾补零再截断——逻辑易错、cache 不友好、且破坏原始数据语义。
立即学习“C++免费学习笔记（深入）”；
- 标准做法：主循环走
i = 0; i ，剩余 <code>n % 8个元素用标量循环单独处理 - AVX2+ 可用
_mm256_maskload_ps，但支持有限（要求地址对齐、mask 为__m256i），且 GCC 对其优化弱 - AVX-512 有原生掩码指令如
_mm512_mask_add_ps，但仅限支持该指令集的 CPU（如 Intel Ice Lake、SPR），别在通用代码里默认启用 - 分支预测成本远高于几个标量加法，所以“主块 + 尾部标量”比“每轮都判断是否越界”更稳更快
为什么写了 intrinsic 还没加速
写了 _mm256_add_ps 却没看到性能提升，往往不是指令问题，而是数据流被卡住了。
- 指针别名（aliasing）：编译器不敢并行化，加
__restrict告知a、b、c互不重叠 - 循环体内有分支（
if）、函数调用或非连续访存（如稀疏数组索引），会打断向量化机会 - 寄存器压力过大：一次用太多
__m256变量，编译器被迫频繁 spill/reload，反而拖慢 - 没开优化：忘了
-O2或-O3，intrinsics 函数体本身不会被内联，性能直接归零 - 用
perf stat -e cycles,instructions,uops_issued.any,uops_executed.core看 IPC 和微指令吞吐，比单纯跑 time 更准
最常被忽略的其实是数据生命周期：SIMD 加速只对“连续、同构、高密度”的计算有效；一旦涉及对象虚函数、动态 dispatch、或间接寻址，就得退回到标量或换用更高层抽象（如 std::simd 或 OpenMP #pragma omp simd）。硬凑 intrinsic 不但无效，还会让代码更难维护。
