根据前面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路推理时，单路推理的时间会变长，但是总的吞吐量提升了快3倍，说明硬件被更充分的利用了。同时每路推理处理的帧数大致相同，大约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过热导致降频，这时候可以听到风扇狂响，这时候性能也会急剧会下降