直接用_mm256_load_ps读图数据常崩或结果错，因图像默认16字节对齐而AVX2要求32字节对齐；未对齐加载会触发非法指令异常或数据错乱，应改用_loadu_ps、alignTo(32)或_aligned_alloc分配内存。
为什么直接用 _mm256_load_ps 读图数据常崩或结果错？
因为图像内存布局和 SIMD 对齐要求不匹配。多数图像（如 OpenCV 的 cv::Mat）默认按行对齐到 16 字节，而 AVX2 要求 32 字节对齐才能安全用 _mm256_load_ps。强行加载未对齐地址会触发 EXCEPTION_ILLEGAL_INSTRUCTION（x86）或静默数据错乱（ARM NEON 某些模式下）。
- 实操建议：用
cv::Mat::create(h, w, CV_32F, cv::Scalar(0))后调用mat.alignTo(32)（需 OpenCV ≥ 4.8），或手动用_mm256_loadu_ps（带 u 表示 unaligned），但性能降约 15–20% - 更稳做法：分配内存时用
aligned_alloc(32, size)（C11）或_mm_malloc(size, 32)，并确保卷积核、输入、输出三者全部对齐 - NEON 注意：
vld1q_f32等指令也要求 16 字节对齐；vld1q_f32_aligned并不存在，必须自己保证指针对齐
卷积核太小（如 3×3）时，手写 AVX 循环反而比 OpenCV cv::filter2D 慢？
因为小核的向量化收益被寄存器调度和边界处理开销吃掉。AVX 每次处理 8 个 float，但 3×3 卷积每行仅需跨 3 像素取数，导致大量 _mm256_shuffle_ps 或标量补位操作，实际吞吐远低于理论值。
- 实操建议：核尺寸 ≤ 5×5 时，优先用 OpenCV 的
cv::dnn::blobFromImage+cv::dnn::Net（其内部已对小核做汇编特化），或启用cv::setUseOptimized(true)+cv::filter2D - 若坚持手写：改用“宽向量展开”——一次计算输出行的连续 8 个点，复用同一组输入向量，减少 shuffle 次数；避免为每点单独重载输入行
- NEON 可用
vextq_f32高效做像素平移，比 x86 的_mm256_shuffle_ps更轻量
怎么让 AVX 卷积在不同图像宽高下都不越界？
边界处理不是加 if 判断就行——分支预测失败会让 AVX 流水线停顿，比计算本身还贵。真正的解法是“预填充 + 向量掩码”，把逻辑从运行时搬到编译期或初始化阶段。
- 实操建议：用
cv::copyMakeBorder提前把输入 pad 到宽度能被 8 整除（AVX）、或 4 整除（NEON），再用纯向量循环遍历有效区域 - 若内存敏感：构造一个
__m256i掩码向量（如低 8 位为 1，其余为 0），用_mm256_blendv_ps在最后几列混合零值；掩码可静态生成，避免每次循环重建 - 注意：OpenCV 的
BORDER_CONSTANT默认填 0，但BORDER_REFLECT等模式无法向量化，必须提前转成 pad 形式
为什么开了 AVX2 编译选项，g++ -O3 -mavx2，但 perf 显示还是跑在标量路径？
因为编译器没敢自动向量化你的卷积循环——常见原因是存在依赖链（如 out[i] += in[i+j] * kernel[j] 中的累加），或指针别名不确定（编译器不敢假设 input 和 output 不重叠）。
立即学习“C++免费学习笔记（深入）”；
- 实操建议：给指针加
__restrict__（GCC/Clang）或[[gnu::restrict]]，例如float* __restrict__ out；消除跨迭代依赖，把累加拆成多个向量暂存再合并 - 强制向量化：用
#pragma GCC ivdep或#pragma clang loop vectorize(enable)放在循环前，但需自行验证正确性 - 验证是否生效：用
objdump -d your_binary | grep vaddps查看是否有 AVX 指令；或用perf stat -e instructions,fp_arith_inst_retired.128b_packed_single看实际执行的 packed 指令数
真正卡住性能的往往不是指令选型，而是内存访问模式——卷积的局部性差，cache line 颠簸比计算延迟影响更大。先用 perf record -e cache-misses 看是不是在反复刷 L3，再调向量化。
