OpenCV中convertTo与LUT性能异常及计时外代码影响原因咨询

测试背景 #

测试基于 OpenCV 4.4.0、CentOS 7.2 Docker、gcc 7.3.1 环境，对比两类归一化方案性能：

• 方案1：调用convertTo将[0,255]范围像素乘1/255.0转换为CV_32FC3格式
• 方案2：预生成查找表调用LUT实现格式转换
  测试覆盖6种常见输入尺寸，采用128张图片循环测试10次，出现三类异常现象，对应成因如下：

异常1：小尺寸输入下LUT性能远低于convertTo，仅大尺寸下LUT有优势 #

• LUT本身存在固定开销：包括函数调用开销、查找表内存随机寻址开销，小尺寸输入下像素总量少，固定开销占总耗时比例超过90%，掩盖了查表无额外计算的优势
• convertTo底层默认启用SIMD指令优化，小数据量下逐元素浮点乘法的SIMD并行计算延迟，远低于LUT的随机内存寻址延迟
• 当输入尺寸足够大时，像素计算总量占比提升，LUT无需逐次做浮点运算的优势开始显现，总耗时会低于convertTo

异常2：注释计时区间外的结果一致性校验代码后，性能数据明显偏移 #

• 核心原因是编译器死代码消除优化：如果归一化计算的输出结果没有被任何代码使用（校验代码被注释后无其他地方读取输出），编译器会直接把未被使用的归一化计算逻辑从二进制中删除，计时结果完全不反映实际计算耗时
• 次要原因是CPU缓存状态变化：保留校验代码时，校验逻辑会读取两个方案的输出内存，会主动刷新上一轮测试留在CPU缓存中的脏数据，每轮测试的初始缓存状态一致；注释校验代码后，上一轮的输出数据可能仍留在缓存中，减少了当前测试的内存访问开销，导致计时偏快

异常3：调整测试尺寸的先后顺序，性能结果大幅波动 #

• CPU睿频/功耗控制影响：现代CPU默认启用动态频率调整，先跑大尺寸负载会快速将CPU频率拉到睿频峰值，后续小尺寸测试可延续高频率状态；若先跑小尺寸负载，CPU可能未完全唤醒，频率处于低水平，后续测试的初始频率状态差异会带来明显耗时偏差
• CPU缓存预热影响：先跑大尺寸输入时，大量像素数据会占满L1/L2/L3缓存，后续小尺寸测试无法命中缓存，需要重新从主存加载数据；若先跑小尺寸输入，缓存占用少，后续大尺寸测试的初始缓存命中率更高，耗时会偏短
• OpenCV内存池机制影响：OpenCV内部会缓存已分配的Mat内存块，先跑大尺寸时会申请大内存块，后续小尺寸测试可直接复用该内存块，无需触发新的内存分配和缺页中断；若先跑小尺寸，后续大尺寸测试需要重新申请更大的内存块，会引入额外的内存分配开销

测试优化建议 #

如果需要得到稳定的性能数据，可做以下调整：

• 测试前将CPU固定为额定频率，关闭睿频和节能模式
• 执行性能计时前先对测试逻辑做10~20次预热跑，让CPU频率、缓存、内存池进入稳定状态
• 保留结果校验逻辑，或主动读取输出Mat的部分数据写入全局变量，避免编译器将计算逻辑优化掉
• 单轮仅测试一个尺寸，每测试完一个尺寸后主动刷新CPU缓存，避免不同尺寸的缓存残留相互干扰

内容的提问来源于stack exchange，提问作者Chester Z