基于openvino 2019R3的推理性能优化的学习与分析 (三) 基于CPU的推理(inference)性能分析

[英特尔开发人员专区]

根据前面2部分对benchmark_app的分析，重新改写了一下benchmark的代码，主要去掉了命令传递参数的方法，所有参数改为代码里hard code;去掉了智能指针之类的高级用法，只使用简单的操作系统提供的多线程同步接口。这么做的目的是为了以后把inference这部分作为一个模块，可以更简单的集成进自己的程序里 :)

首先看一下纯CPU的mobilenet-ssd FP32模型的推理性能, 我手里是个i5 7440HQ的4核4线程的移动处理器,

首先batch size = 1，即每次推理只输入一张图片,

inference request(nireq) = 1时，即同时只有一个推理请求



每推理100帧计算打印一下单次推理所需的时间Latency（us），以及总的推理性能throughput (FPS)

此时Latency为28ms左右, Throughtput为36FPS

inference request(nireq) = 4时，即设置CPU_THROUGHPUT_STREAMS = CPU_THROUGHPUT_AUTO时，openvino建议的并发数为4， 同时并发4个推理请求



此时Latency为40ms左右, Throughtput为96FPS

可以看到同时并发4路推理时，单路推理的时间会变长，但是总的吞吐量大大提升，说明硬件被更充分的利用了。同时每路推理处理的帧数大致相同，大约25frame左右，一致性还不错，基本上可以保证先推理先结束

接下来看看batch size = 3，inference request(nireq) = 4时。即每次推理处理三张图片, 4路推理并发



随着单次推理数据的增大，单帧Latency略有变大(这里代码写错了，真实数字应该除以9），FPS也略有下降。增大单次数据量对性能反而有负面影响。说明硬件的处理能力也就这么回事了，再多的数据也只能增加程序反复调度的开销，无法在性能上再进一步了。

最后测一下纯CPU的mobilenet-ssd FP16模型的性能，发现性能和FP32基本一致。这也印证了openvino官网上说的, CPU的推理时，如果加载FP16的模型，会在加载时把FP16转为FP32

简单总结一下，OpenVINO的CPU推理

推理并发数决定了Lantency的大小，如果需要快速得到推理结果，最好并发数为1，即让openvino集中所有硬件做单次推理。如果要获得高吞吐量，则需要增多并发数。
CPU推理时的"CPU_BIND_THREAD"基本是鸡肋，因为并不能指定bind到哪颗物理内核，所以可能会造成负面影响(和其他代码都绑到同一个物理核上）
CPU推理时加载FP32/FP16模型，推理性能是一样的
CPU推理非常容易受到后台程序的影响，比如后台的病毒扫描，或者windows update线程，性能可能会下降超过10%
极限挖掘CPU推理性能时很容易造成CPU过热导致降频，这时候可以听到风扇狂响，这时候性能也会急剧会下降

[dv_zheng]

6666666666666666666666666666

[weixin_42066565]

来学习来学习

[Giberson1]

这不就是超频吗，寿命骤降意义不大。耗损的寿命不如加点钱，去买个配置更好的GPU产品，你这种尝试毫无意义，只是在菜鸟前面放大招，奥利给。

[hookee]