Skip to content
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

请问为何 Mkldnn 在 ChineseV4 下运行会比 Onnx 和 Openblas 慢很多? #75

Closed
qaqz111 opened this issue Dec 5, 2023 · 9 comments

Comments

@qaqz111
Copy link

qaqz111 commented Dec 5, 2023

按 Readme 里面的说明来看,貌似 mkl 比 openblas 是要快的,
在我的机器(R7-5800H 16G Win10 22H2)上跑出来的耗时对比如下:

  • LocalFullModels.ChineseV3

    • PaddleDevice.Mkldnn() => 1.24秒
    • PaddleDevice.Openblas() => 2.1秒
    • PaddleDevice.Onnx() => 1.31秒
  • LocalFullModels.ChineseV4

    • PaddleDevice.Mkldnn() => 10.2秒(没错就是 10+ 秒)
    • PaddleDevice.Openblas() => 2.12秒
    • PaddleDevice.Onnx() => 1.6秒

ChineseV3 模型基本符合 Readme 的描述,
但是用 ChineseV4 模型 mkl 明显慢于其他两个,
而且其他两个跑 V4 也不如在 V3 上快。

上面的耗时数据是使用默认参数创建 PaddleOcrAll 对象的情况下得到的,
请问在参数上进行调整能让 V4 模型耗时降下来吗?
尤其是 mkl 的耗时,谢谢。

@n0099
Copy link
Contributor

n0099 commented Dec 5, 2023

@qaqz111
Copy link
Author

qaqz111 commented Dec 6, 2023

intel oneapi mkldnn本就是amd黑 https://www.pugetsystems.com/labs/hpc/How-To-Use-MKL-with-AMD-Ryzen-and-Threadripper-CPU-s-Effectively-for-Python-Numpy-And-Other-Applications-1637/ https://mattermodeling.stackexchange.com/questions/1103/since-mkl-is-not-optimized-for-amd-hardware-should-i-use-a-math-library-specifi https://news.ycombinator.com/item?id=21732902 pytorch/pytorch#26534

而v4模型所需的新版本>2.5paddleinference所用的libmkldnn.so.0比之前版本更加amd黑了 我之前用v3模型在azure的ubuntu2204vmAMD EPYC 7763上跑起来跟Intel Xeon Platinum 8370C耗时差不多 但换v4模型和paddleinference>2.5后也像您这样慢了差不多10倍导致被迫换intelcpu

我去。。。之前我也在网上搜了一圈,确实看到有说 mkl 对 AMD 负优化的,但是没有深入去找更多信息,还以为是谣言来着,想着可能是对 paddle 不熟研究看看调参数行不行。。。看来还是折腾下 GPU 环境吧。

感谢提供的链接,尤其是第一篇 post,基本能锤死 mkl 是个 amd 黑了 /泪奔

@n0099
Copy link
Contributor

n0099 commented Dec 6, 2023

您试试看我之前用于v3模型不那么amd黑的老版本2.4.2paddleinference能否使用v4模型并输出正常文本

@qaqz111
Copy link
Author

qaqz111 commented Dec 6, 2023

谢谢,折腾一阵之后,用 mkl+V3 模型调整到了 0.7 秒完成一次识别,勉强算可以接受了。
我的工程目标是运行在windows环境下的C#程序,您提供的包是 linux 的二进制库和头文件,不能直接放进我现有的工程里,我对 linux 的开发也不是很熟,就不多折腾了,还是要感谢您提供的信息和帮助,谢谢!

@n0099
Copy link
Contributor

n0099 commented Dec 6, 2023

@sdcb
Copy link
Owner

sdcb commented Dec 7, 2023

这个好像也和AMD没有的关系,是和这个问题有关:PaddlePaddle/PaddleOCR#10346
三个排列组合时:V4模型、CPU不支持AVX512、Mkldnn
速度会变慢,上面3个排列组合任意一个不满足,速度都快

@qaqz111
Copy link
Author

qaqz111 commented Dec 7, 2023

这个好像也和AMD没有的关系,是和这个问题有关:PaddlePaddle/PaddleOCR#10346 三个排列组合时:V4模型、CPU不支持AVX512、Mkldnn 速度会变慢,上面3个排列组合任意一个不满足,速度都快

原来是这个原因,查了下 R7-5800H 确实不支持 AVX512,看来 mkl 在我现在用的机器上确实不适合跑 V4 模型,谢谢大佬解惑!

由百度编译的win的paddleinfer不就在下面 https://paddleinference.paddlepaddle.org.cn/user_guides/download_lib.html#windows https://paddle-inference-lib.bj.bcebos.com/2.4.2/cxx_c/Windows/CPU/x86-64_avx-mkl-vs2017/paddle_inference_c.zip

谢谢,因为目前调整到可以接受的程度了,我就没仔细看您发的链接地址,只打开链接下载的包看了下,我以为是您自己从源码编译的。那个飞桨的页面也多次翻到过,但是并没有下旧版本的回来试过(还没有走到那步吧,想先试试其他法子能不能解决问题),而且 VS C# 的开发习惯还是喜欢直接用一键安装的 nuget 包不用自己折腾,所幸现在已经调整出可以接受的方案了。并且楼上大佬已经指出了问题原因,不然可能确实还得按您说的逐个降级版本来试。

@qaqz111 qaqz111 closed this as completed Dec 7, 2023
@n0099
Copy link
Contributor

n0099 commented Dec 7, 2023

这个好像也和AMD没有的关系

然而22年9月amd发布的zen4microarch才支持avx512指令集
https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
https://news.ycombinator.com/item?id=36711033

查了下 R7-5800H 确实不支持 AVX512

EPYC7763和您的R7-5800H同属上一代zen3
等服务器级u慢慢换上去还得好几年,建议直接换18年cannonlakemicroarch起就部分支持了的intel u

我以为是您自己从源码编译的

我又不是百度员工,隔壁友商 @raoyutian 才是 raoyutian/PaddleOCRSharp#28 (comment)
自行编译百度这一套远古依赖链屎山项目简直就是梦魇 https://z.n0099.net/#narrow/near/83265

cc @yangbowen

那个飞桨的页面也多次翻到过,但是并没有下旧版本的回来试过

百度文档万年不更新最新版本url还停留在22年8月时的2.3.2
还好他们不同版本的预编译artifacts文件url都十分固定可以猜出来

由百度编译的win的paddleinfer不就在下面 paddleinference.paddlepaddle.org.cn/user_guides/download_lib.html#windows paddle-inference-lib.bj.bcebos.com/2.4.2/cxx_c/Windows/CPU/x86-64_avx-mkl-vs2017/paddle_inference_c.zip

@n0099
Copy link
Contributor

n0099 commented Dec 7, 2023

迫真amd黑 https://z.n0099.net/#narrow/near/89147

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants