_mm256_add_ps不能直接用于求和，因为它执行的是8元素向量对应位置相加，输出仍是8元素向量，而求和需将8个结果归约为1个标量，必须通过水平加法或分段累加+标量合并实现。
_mm256_add_ps 不能直接用于求和——它做的是向量加法，不是归约（reduction）。想用 AVX 加速数组求和，必须手动实现水平加法（horizontal add）或分段累加 + 标量合并，否则你写的只是“并行加法”，不是“并行求和”。
为什么 _mm256_add_ps 不能直接求和？
它把两个 8 元素 float 向量对应位置相加，输出仍是 8 元素向量：_mm256_add_ps(a, b) → {a₀+b₀, a₁+b₁, ..., a₇+b₇}。而求和需要把这 8 个结果加总成 1 个标量。CPU 没有单条指令能直接把 8 个 float 水平加到一起；必须靠多步 shuffle + add 组合实现。
AVX 求和的正确写法：分块累加 + 水平归约
核心思路是：用向量寄存器维护多个部分和（如 8 个独立累加器），最后再把它们加总。避免频繁 store/load，减少数据搬运开销。
- 分配一个
__m256 sum_vec = _mm256_setzero_ps()作为初始累加器 - 主循环每次加载 8 个 float →
_mm256_load_ps(&arr[i])→ 累加进sum_vec：sum_vec = _mm256_add_ps(sum_vec, _mm256_load_ps(&arr[i])) - 循环结束后，用
_mm256_hadd_ps+_mm256_shuffle_ps或更稳妥的两步法提取最终标量：float temp[8]; _mm256_store_ps(temp, sum_vec); float total = temp[0] + temp[1] + temp[2] + temp[3] + temp[4] + temp[5] + temp[6] + temp[7]; - 若追求极致性能，可用
_mm256_extractf128_ps拆成两个 128 位向量，再用_mm_add_ps+_mm_hadd_ps归约，但可读性差、编译器优化易失效
对齐与尾部处理不处理，_mm256_load_ps 就会崩溃
AVX 要求 32 字节对齐（即地址 % 32 == 0），否则 _mm256_load_ps 触发 EXC_BAD_ACCESS 或静默降级到慢路径。堆上分配必须用 aligned_alloc(32, size) 或 _mm_malloc(size, 32)；栈上变量加 alignas(32)。
立即学习“C++免费学习笔记（深入）”；
- 数组长度通常不是 8 的整倍数 → 主循环处理
n - (n % 8)个元素，剩余n % 8个用标量循环补全 - 千万别混用
_mm256_load_ps（要求对齐）和_mm256_loadu_ps（错位容忍但有开销）在同一逻辑里——后者在某些 CPU 上触发微码补丁，反而比标量还慢 - 确认指针对齐：
(uintptr_t)arr % 32 == 0，否则宁可全用_mm256_loadu_ps并接受轻微损失，也别让程序崩
编译器自动向量化 vs 手写 SIMD：别让两者打架
如果你开了 -O3 -mavx，GCC/Clang 可能自动把你的标量求和循环向量化——这时你手写的 AVX 代码不仅没收益，还可能因干扰编译器调度而变慢。
- 要确保手写 SIMD 生效，得禁用自动向量化：
__attribute__((optimize("O3,no-tree-vectorize")))加在函数上（GCC/Clang） - MSVC 用
#pragma loop(ivdep)和#pragma vector(novector)控制 - 实测中，纯手写 AVX 求和在 >10k 元素时才稳定优于编译器自动向量化；小数组反而更慢（启动开销+寄存器压力）
真正难的不是写那几行 intrinsic，而是判断“此刻该不该用 SIMD”：数据是否对齐、长度是否足够、内存带宽是否瓶颈、是否和其他向量化代码共存（比如调用了 OpenCV 的 SSE 函数后立刻切 AVX，忘了 _mm256_zeroupper()，性能直接腰斩）。这些细节不盯住，加速就变成减速。
