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

英特尔边缘计算社区 英特尔(中国)有限公司 2020-09-28 04:04:58
加精
根据前面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过热导致降频,这时候可以听到风扇狂响,这时候性能也会急剧会下降
...全文
46731 点赞 收藏 4
写回复
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
hookee 03-06
回复
Giberson1 01-13
这不就是超频吗,寿命骤降意义不大。耗损的寿命不如加点钱,去买个配置更好的GPU产品,你这种尝试毫无意义,只是在菜鸟前面放大招,奥利给。
回复
weixin_42066565 2020-11-16
来学习来学习
回复
dv_zheng 2020-10-24
6666666666666666666666666666
回复
相关推荐
发帖
英特尔边缘计算技术
创建于2007-08-27

450

社区成员

英特尔® 边缘计算,聚焦于边缘计算、AI、IoT等领域,为开发者提供丰富的开发资源、创新技术、解决方案与行业活动。
申请成为版主
帖子事件
创建了帖子
2020-09-28 04:04
社区公告
暂无公告