Open ysh329 opened 3 years ago
mace/mnn/tnn/ncnn/tflite/mindspore:http://agroup.baidu.com/paddle-infer/view/office/2539063
6个机型990/980/970/855/845/835。4个模型caffe/tf的mobilenetv1v2。
测了 【kernel(profile的k-average)整体耗时】 v3-int8-model: 5.908ms v3-float-model: 7.503ms 补充:repeats=10000,warmup=100 环境:v2.1.0, OMP_OFF,PROFILE,ADD_DETECT_KERNELS_OPS,test_mobilenetv1_int8 【模型整体耗时】 v3-int8-model: 10.969 ms v3-float-model: 11.951 ms 补充:repeats=10000 环境:v2.1.0, OMP_OFF,ADD_DETECT_KERNELS_OPS,tiny_pulish的cxx-demo-mobile_light,libc++_shared 【框架整体耗时-kernel的Run方法直接return】 v3-int8-model: 0.3095 ms v3-float-model: 0.3269 ms 环境:v2.1.0, OMP_OFF,SHUTDOWN_LOG_ON,ADD_DETECT_KERNELS_OPS,tiny_pulish的cxx-demo-mobile_light,libc++_shared 总体来看以上3部分: kernel整体耗时,int8比float快 1.6 ms 模型整耗时,int8比float快 1.0 ms 框架整体耗时,int8比float快 0.02 ms 分析: int8 kernel比float确实有性能优势。kernel总体耗时,int8(5.9ms)比float(7.5ms)快 1.6 ms; 模型整体耗时相近,可能被框架本身慢和模型差异带慢了。模型整体耗时,int8(10.9ms)比float(11.9ms)快 1.0 ms; 模型整体耗时排除kernel总体耗时,也就是带profile的框架耗时,int8(5.0ms)比float(4.4ms)慢了0.6 ms,这个 0.6, 似乎是int8和float模型差异,导致的慢0.6ms的原因。另外可能就是框架本身慢。 框架整体耗时,没法体现模型差异慢,似乎模型差异慢是开了profile的缘故,与前面模型差异慢的结论矛盾,int8(0.30ms)比float(0.32ms)快 0.02 ms; 仍需进一步长线分析
2月
【本周计划,周五已汇总更新(红字)】 【已完成,APP包内体积为260KB】模型批量裁剪vis的15个模型(11个vis的,4个手百的),看看包体积大小是多少; 【已完成,精度下降,下周再试新feature】int8量化精度有修复(陈姣),查看int8 mv6s模型的精度是否有提高。 【周一】 模型批量裁剪根据文档,发现目前脚本有问题,已经反馈志强,等待修复; 【周二】 1.模型批量裁剪问题已修复,根据对15个模型(11个vis+4个手百),armv7-cpu的库(tiny_publish,android_stl_shared),体积如下: ./libpaddle_light_api_shared.so:684K; ./libpaddle_light_api_shared.so.zip:260K(APP包内体积)。 2.int8量化精度修复看mv6s精度是否提高,进行中。将93张图片,lite的结果跑出来了,需要与hanqi联调比对fluid的结果。精度下降了,在93张的lite结果和fluid-gpu比,因为是关键点模型,lite和fluid-gpu的输出元素值逐个比对的,最大diff增大(最大diff先前是0.78,现在是1.68)。后续arm cpu在int8量化的lite层面还会做一些精度上的优化。
2月17日
2.17 本周进展: 模型批量裁剪,对15个模型(11个vis+4个手百),armv7-cpu的库(tiny_publish,android_stl_shared),APP包内体积 260K。 int8量化精度有修复,查看int8 mv6s模型的精度,在93张图片上比较lite和fluid-gpu结果发现精度误差增大,后续arm cpu在int8量化的lite层面还会做一些精度上的优化,等待后续优化。
3月
v2.3精度有修复,重测v4.5模型在93张图上的精度。目前我这里测精度与先前v2.1无提升(最大diff与先前一样,无变化),但@陈姣 那里用dev分支(int8修复部分与v2.3无变化)测有巨大与fluid一致
【周一】 提供用于QA测试 int8 v45人脸关键点模型的文档和脚本。 写了供QA参考的测试精度文档:人脸关键点v45 int8模型在PaddleLite release/v2.3的批量图片精度验证; 重写了批量生成93个bin的编译+运行+与fliuid批量比对的脚本; 自己复测后v2.3-armv7-cpu,lite与fluid-gpu在93张图片上的abs_diff与v2.1接近,0.78,相对误差0.06(因为是人脸关键点模型,所以看相对误差可能意义不大)。具体见表格的第一个子表sheet; 结果与陈姣确认,此外,和陈姣讨论,因为考虑到QA工作重复,先不找QA提测。 与张晰、晓刚一起看祥达上周反馈的paddle多线程在AR环境里计算结果错误的问题,编译ios找出当初有错的包等。 张晰 验证2.3分支的ios包,不存在该问题; 想确定问题版本commit id,但vis那边找不到了原压缩包。注:先前@袁帅 提供包,commit-id一并打包压缩。
【周二/周三】 mv3模型lite性能低于anakin。与陈姣、张晰测试mv3、mv45模型在高通625上的性能。 发现lite比anakin慢的原因:relu6+dwconv的融合的relu6判断影响性能, 除@陈姣 反馈的结论外,从详情见表格;可以看到: 开启OPENMP,降低单线程性能5%(来自lite基于mv45模型): clang编译,性能相比gcc编译提升6%(来自anakin基于mv45模型)。
paddledetection【TODO】 背景:发现profiler里tf和lite卷积个数不一致,反馈给青青方面,提供新的ssd mobilenetv3模型,比较lite与tflite在armv8 cpu单线程上的性能; 状态:ssd-mobilenetv3青青方面@于广华 提供新模型,还在查模型paddle与tf的差异
OpenCL 业务支持
LiteKit手机端OPENCL和CPU模型(已经开源)
2个GPU模型,手势检测与超分,1个cpu模型,人像分割;
手百lens手机端OPENCL和CPU业务(已经上线)
男女变换GAN手机端OPENCL模型(未上线,算法未调整好)
反黄反暴力手机端OPENCL模型(未上线,算法未调整好)
图像修复手机端OPENCL模型
如流人像分割手机端OPENCL模型(准备上线)
如流人像分割PC端OPENCL模型(准备上线)