cv::resize不能直接进simd流水线，因其通用实现含分支判断、动态分配、浮点除法和非对齐访存，打断向量化；热点在插值系数计算与边界检查，无法被编译器自动向量化。
为什么 cv::resize 不能直接进 SIMD 加速流水线
因为 OpenCV 默认的 cv::resize 是通用实现，内部有分支判断、动态内存分配、浮点除法和非对齐访存——这些都会打断向量化执行。即使你用 AVX2 编译，它也不会自动变成每周期处理 32 个像素的版本。
- 实际部署中，
cv::resize常占预处理 60%+ 耗时，但它的热点在插值系数计算和边界检查，这两块根本没法被编译器 auto-vectorize - 真正能压满 SIMD 单元的是“固定尺寸 + 固定缩放比 + uint8 输入 + BGR 顺序”的场景，比如 YOLOv5 的 640×640 推理前处理
- 别试图用
#pragma omp simd包裹原生 resize —— 数据依赖太强，编译器会静默退化成标量循环
怎么写一个真正跑满 AVX2 的 resize_bilinear_u8
核心是把“双线性插值”拆成可并行的整数运算：用定点缩放代替浮点除法，用查表 + 向量 shuffle 替代条件跳转，输入输出都强制 32 字节对齐。
- 输入图像宽必须是 32 的倍数（不足补零），高不限；目标宽也必须是 32 的倍数——这是 AVX2 批处理的前提
- 缩放因子提前算好：比如从 1920→640，就预计算
scale_x = 3和frac_x = {0,1,2,0,1,2,...}这种周期为 3 的向量 - 关键操作用
_mm256_shuffle_epi8做像素重排，用_mm256_maddubs_epi16做 8-bit × 8-bit → 16-bit 插值加权，避免任何 if 分支 - 示例片段：
__m256i src0 = _mm256_loadu_si256((__m256i*)(src_row + x)); __m256i src1 = _mm256_loadu_si256((__m256i*)(src_row + x + 1)); __m256i w0 = _mm256_shuffle_epi8(weights_lo, frac_mask); __m256i w1 = _mm256_shuffle_epi8(weights_hi, frac_mask); __m256i interp = _mm256_maddubs_epi16(_mm256_unpacklo_epi8(src0, src1), _mm256_unpacklo_epi8(w0, w1));
torch::jit::script::Module 加载后调用 forward 前，为什么必须做 to(at::kCUDA) 和 eval()
不是习惯问题，是 JIT 模块的图优化策略依赖设备与模式标记：没 eval() 时 dropout/batchnorm 仍按训练逻辑走，没 to(kCUDA) 时所有 tensor 默认在 CPU，导致 kernel 启动失败或隐式拷贝拖慢 5–10 倍。
-
eval()不只是关 dropout——它还会触发 JIT 的 shape propagation 优化，让后续resize预处理输出张量的 stride 与模型期望完全一致 - 如果先
to(kCUDA)再eval()，某些旧版 LibTorch（1.10 之前）会触发 CUDA context 初始化 bug，建议顺序固定为module.eval().to(device) - 别信文档里“自动推断设备”的说法：JIT 模块的
forward输入 tensor 设备必须显式匹配，否则报错是CUDA error: invalid argument，而不是清晰的 device mismatch 提示
预处理模块和推理引擎之间传数据，为什么不能用 std::vector<uint8_t></uint8_t>
因为 std::vector 的内存不保证 32 字节对齐，而 AVX2/AVX-512 指令（如 _mm256_load_si256）要求地址末 5 位为 0；同时 vector 的 move 构造在跨 DLL 边界时可能引发 ABI 不兼容崩溃。
立即学习“C++免费学习笔记（深入）”；
- 正确做法是用
aligned_alloc(32, size)或std::pmr::polymorphic_allocator（C++17）配自定义对齐策略 - 更稳妥的是复用推理引擎的内存池：比如 TensorRT 的
IExecutionContext::enqueueV2入参要求void**，直接把预处理输出 buffer 地址塞进去，避免中间拷贝 - 常见错误现象：
Segmentation fault (core dumped)出现在第 37 帧之后——其实是未对齐访存触发了 SIGBUS，但 GDB 显示在无关函数，本质是 AVX 指令踩到了页边界
