-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize inference performance of ERNIE on CPU #180
Comments
全量结果
|
单线程 10个数据
|
20线程,10个sample
|
ERNIE BERT 分析.pdf 主要结论为
|
一个需求: layernorm 多线程
|
Next step 1. mkl sgemm 尺寸测试在ernie中在paddle中单独测试,包含了每次iteration刷新矩阵X。2. 去掉锁。PaddlePaddle/Paddle#196243. 更优可以layernorm的多线程问题。 |
@tensor-tang
export OMP_NUM_THREADS=20
export KMP_BLOCKTIME=1
export KMP_AFFINITY=granularity=fine,compact,1,0
numactl --cpunodebind=0 --membind=0 CMD
|
paddle的单侧数据我们也测了,20threads 时是600us左右,貌似跟你这里的结果不一致呢。 |
UT 单测和我们的数据一样吗? |
#180 (comment) 就是这里的,应该一样。 |
我更新了 |
嗯赞,那先首要一起分析下多线程问题。 |
结论Ernie 20 线程瓶颈在 L3 和 DDR, 原因是Ernie MKL 在20 线程的时候走了不同于TF 的MKL path。由于TF 中添加了Padding,如下
但Ernie 中没有,这个Padding 会导致Ernie 走到了另一个比较差的MKL path,解决方法是在Paddle中添加padding,我会先尝试一下。 |
上面的结论只适用于 AVX512, AVX2 是正常的 |
感谢,但是关于padding我们已经尝试过了,多线程问题不在于padding与否,数据我们之前应该都已经同步过了。 其次,根据你现在的结论,那依然解释不了为什么在paddle中多线程没问题,然而在erinie时有问题。 |
这个现场很重要啊,我们可以也试下。
这里可以麻烦再介绍详细点吗 |
|
Vtune 显示 Gaowei8 padding branch 走的和 TF 一致 耗时对比MKL VERBOSE
基本可以认定, 加了padding 之后 Ernie 和 TF 在 model 整体耗时
@GaoWei8 麻烦更新下 在docker 中的 benchmark 数据 |
使用numactl绑定cpu,最新 ernie 整体耗时36.17ms。 |
目前的结论是 padding 之后
|
@GaoWei8 更新 padding 后单线程 数据 |
@zhaify |
@zhaify |
padding memory time cost 包含 |
2019-10-14 Ernie 多线程排查报告总结背景简要说明:
同时 Intel 也在 6248上(和6148配置相似)复现了和百度相似的多线程 benchmark[4], 如下:
Ernie 的多线程性能落后竞品 TF ~3x, 复现 Intel benchmark 参考 Github readme[5] 详细信息参考 issue 180, Luotao 的总结, 以及 Bingyang 的 ERNIE BERT 分析. 实验和结论comment 做了 M=128, K=768, N=3072 的三组实验
得到的结论是:
推测原因是 因为不同的 MKL path 导致的, 而 padding 是导致了相同 Gemm 操作走不同 MKL path. comment 测试了 添加 和 TF 相同的 padding 之后 MKL_VERBOSE 打出的 Gemm 耗时, 如下
可以看出加上 padding 之后 MKL_VERBOSE 打出的 同时文章[6]建议当用 MKL 做 Gemm 操作的时候, 如果 size 是 128 的整数倍, MKL_sgemm 的多线程性能急剧下降, 此时需要对Gemm 的维度做 padding 以方式性能损失. 但是加 padding 之后 model 性能测试如下, 发现 Ernie 仍旧慢于竞品 37%
comment 测试了为了 padding 额外做的内存申请,数据拷贝以及内存释放的时间,如下
可以看出这部分时间占总时间的 10% 也就是 3.77s, 去除掉这部分耗时可以得出 Ernie 和 TF 还有 23% 的性能差距. 下一步
[1] 用 Paddle 预测库跑 BERT Inference. |
@zhaify |
padding能否 @bingyanghuang @jianhang-liu 来帮忙做一下?因为mkl内部对对线程应该能有更好的控制,可能性能会好一些。同时外面的多线程跟mkl内部的多线程策略可能不一样,会影响性能。 |
@zhaify
5个OP在单线程中时间占比 |
@zhaify
|
@luotao1 @bingyanghuang
|
@bingyanghuang 具体OP分析:(主要关注耗时增加的OP)
|
@bingyanghuang |
@bingyanghuang |
@bingyanghuang 具体OP时间变化趋势 |
@bingyanghuang |
@bingyanghuang |
Intel ARs:
Baidu ARs
|
我们分别对比了 Erinie 和 TF 在单线程和多线程下 GEMM 耗时,结果如下:
因此可以初步得出 Ernie 下一步优化集中三部分:
|
测试layernorm多线程结果#20895
layernorm OP 耗时
profile结果:
优化后:
|
基于现在情况的总结和大fusion的建议。 |
@bingyanghuang 实验&分析 实验:
疑惑:造成数据0,1耗时相差过大的原因, |
全数据集数据 |
关于统一数据集和@bingyanghuang的讨论:
初步结论:
|
@bingyanghuang
绑核
|
@GaoWei8 请补充下绑核的命令 |
负责人
@tensor-tang @GaoWei8
机器型号
6148
commit号
based on #164
初始性能
10个sample
profile 结果
TODO
去掉load @tensor-tang,不会统计进预测时间,可以忽略The text was updated successfully, but these errors were encountered: