cv::filter2d性能通常已足够，盲目手写simd易出错；真需优化应先定位瓶颈，注意内存对齐、边界处理、数据类型选择及openmp与simd协同问题。
cv::filter2D 性能不够？先确认是不是真需要手写 SIMD
绝大多数场景下，cv::filter2D 已经用了 SSE/AVX 优化，尤其在 OpenCV 4.5+、编译时启用了 CPU_BASELINE=AVX2 的情况下。盲目手写 SIMD 不仅开发成本高，还容易因内存对齐、边界处理出错导致结果偏差或崩溃。真要提速，先用 cv::getTickCount() 对比 baseline，再看热点是否真卡在卷积计算本身——很多“慢”其实是 ROI 拷贝、类型转换（如 CV_8UC3 → CV_32FC3）或非连续内存引起的。
手动 SIMD 卷积：必须处理好内存对齐和边界
AVX2 处理 32-bit float 时一次拉 8 个元素，要求输入行地址、滤波器系数、输出缓冲区都按 32 字节对齐。OpenCV 的 cv::Mat 默认不保证行对齐（mat.step 可能是 1280 而非 1280 对齐到 32），直接传给 _mm256_load_ps 会触发 segmentation fault。常见做法：
- 用
cv::Mat::create(height, width, CV_32F, cv::USAGE_ALLOCATE_SHARED)+cv::Mat::alignSize()预分配对齐内存 - 边界处改用
_mm256_loadu_ps（带 u 表示 unaligned），但性能下降约 15–20% - 卷积核尺寸 > 3×3 时，避免逐像素展开；改用 im2col + GEMM 模式更易向量化，但需额外内存
float vs int16：SIMD 指令选型直接影响吞吐
图像卷积常用 float32，但移动端或嵌入式常转成 int16 用 NEON 或 AVX-512 VNNI 加速。关键差异：
-
_mm256_cvtepu8_epi16可把 8 个 uint8 像素转为 8 个 int16，但需先减去均值（如 128）避免溢出 - int16 卷积核必须也转成 int16，且累加不能用
_mm256_madd_epi16直接乘加——它要求 kernel 是 int16、input 是 int16，结果是 int32，但中间乘法会饱和 - float32 下用
_mm256_mul_ps+_mm256_add_ps更直观，但要注意_mm256_store_ps前必须确保目标地址 32-byte 对齐，否则 SIGBUS
OpenMP + SIMD 混合并行容易踩的坑
单纯加 #pragma omp parallel for 处理每行，再在内层用 AVX，看似合理，实际可能因 false sharing 导致性能反降。典型问题：
- 多线程写同一 cache line（如 64 字节）的不同 output 元素，引发 core 间缓存同步开销
- 未用
schedule(dynamic, 4)导致小图分块不均，某些线程空转 - 忘记
private(i, j, sum)，变量被意外共享，结果错乱 - OpenMP runtime 与 AVX 状态寄存器冲突（尤其 Windows MSVC），建议编译时加
/Qvec-report:2确认自动向量化是否生效
真正省事又靠谱的做法：用 OpenCV 的 cv::setNumThreads(0) 关掉内置并行，自己用 TBB 或 std::thread 控制外层分块，每块内用纯 SIMD，边界单独处理。复杂点在于 padding 和 stride 计算，但至少结果可控。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
