iog模型相同的网络结构和输入图片，不同的网络参数，在跑前向计算时间差异大

[luotao1]

问题描述

发现相同的网络结构和输入图片，不同的网络参数，在跑前向计算时间差异有25倍（只有load的参数不一样，其他全部一致，环境也是一样的，代码也一样）。
经过排查，发现【同样大小的矩阵乘，MKL_SGEMM速度差距大】：
1） 使用MKL_VERBOSE=1观察，日志中只调用了MKL_SGEMM函数。而同样大小的矩阵乘，MKL_SGEMM速度差距非常大
a) 跑的慢的模型，如前两个GEMM，分别是849.51ms和75.78ms

b) 跑的慢的模型，如前两个GEMM，分别是114.44ms和1.46ms。差距在7倍到70倍左右

2） 跑的慢的模型，有300M；跑的快的模型只有200M
3） 因此，我们怀疑模型参数中0的数量，会影响GEMM的性能。统计了下参数中0的数量，跑的慢的模型有593个0，而跑的快的模型有1884个0.

请问除了0的个数外，还有其他因素会影响同样大小的矩阵乘的速度么

[luotao1]

@yinghu5 的建议回复：

我们做假设：以下的结果是做同样大小的矩阵乘法，在同样的硬件条件下结果应该有类似的 MKL Verbose 速度。现在有很大的差距
所以我们第一方向，确认硬件条件：

1． 目前这台机器可以采集Vtune arch 结果？
还记的我们还有高欢上次有一个类似现象的 （不过多线程），那个case是memory 的问题， 大的模型，已经超出L3 cache, 要用 memory ， 小模型 可以装在整个cache里， memory vs. cache 速度上是上十倍慢， 所以性能上有上十倍的差距。

可以采集Vtune结果，具体是在docker内部开了两个窗口采集的。

• 一个窗口跑python test.py命令，另一个窗口通过top找到进程号，使用amplxe-cl -collect hotspots -run-pass-thru=--no-altstack -target-pid=xxx 来收集的。
• 原因是这个程序前面会加载模型，加载模型这段略慢。
• 跑出来的结果只能定位到python.so，求问命令使用方式上有什么不对的地方么？

2． 这个机器上还有其他跑的instance ， 或者同时还有其他paddle 线程？

这台机器上没有其他的instance，也没有其他paddle线程了。

3． 机器是虚拟机吗， 跑到超线程机器上去了吗？有线程和物理核控制吗

是物理机。并没有做线程和物理核的控制

如果在任何机器上都能再现，可以装个Vtune 跑跑看，具体情况。

在任何机器上都能复现

[luotao1]

@yinghu5 的建议回复：

是的，vtune 目前只看到Python 或者试试系统采集：/opt/intel/oneapi/vtune/2021.1.1/bin64/vtune -collect hotspots -knob sampling-mode=hw -knob enable-stack-collection=true --duration unlimited。这里是具体步骤
https://software.intel.com/content/www/us/en/develop/documentation/vtune-cookbook/top/configuration-recipes/profiling-in-docker-container.html
和 有一张vtune 的图供你参考

我尝试了系统采集方法amplxe-cl -collect hotspots -knob sampling-mode=hw -knob enable-stack-collection=true --duration unlimited。### 可以看到libmklml_intel.so，但还是看不到内部gemm调用。请问命令上还有哪里不对的地方么？
r000hs (1).tar.gz

还有您的vtune 的版本是什么， 最好装一个最新的oneAPI Vtune上的https://software.intel.com/content/www/us/en/develop/tools/oneapi/base-toolkit/download.html

我的vtune版本是vtune_amplifier_2019.2.0.588069

[yinghu5]

1. 请试试这个 uarch 的采集
   /opt/intel/oneapi/vtune/2021.1.1/bin64/vtune -collect uarch-exploration --duration unlimited

2. 快的模型 和慢的模型， 有MKL verbose 的分别log 和分别 Vtune 采集后的结果吗，我们对比 libmklml_intel.so 的情况看看

3. 原因是这个程序前面会加载模型，加载模型这段略慢。
   为了简便起见，我们就直接系统采集。 vtune 可以支持 customer task 采集， 或者 启动都先让 程序load， 然后在 click 开始采集， 这些需要时我们再启用

[luotao1]

@yinghu5

1. 请试试这个 uarch 的采集

会出现以下错误，且在网上没有找到对应的解决方案

$ amplxe-cl -collect uarch-exploration --duration unlimited
amplxe: Warning: To profile kernel modules during the session, make sure they are available in the /lib/modules/kernel_version/ location.
amplxe: Error: The following events cannot be collected: FRONTEND_RETIRED.LATENCY_GE_16_PS,FRONTEND_RETIRED.DSB_MISS_PS,FRONTEND_RETIRED.L2_MISS_PS,FRONTEND_RETIRED.LATENCY_GE_2_BUBBLES_GE_1_PS,FRONTEND_RETIRED.STLB_MISS_PS. Consider removing the events from the collection, loading the VTune Amplifier sampling driver using the root credentials, or updating the OS kernel.

2. 快的模型 和慢的模型， 有MKL verbose 的分别log 和分别 Vtune 采集后的结果吗，我们对比 libmklml_intel.so 的情况看看

MKL verbose的分别log见：fast.log slow.log

分别 Vtune 采集后的结果：我使用系统采集amplxe-cl -collect hotspots -knob sampling-mode=hw -knob enable-stack-collection=true --duration unlimited的结果如下 fast.tar.gz slow.tar.gz

有几个说明：

1. MKL verbose的log是原始程序的日志，即分别跑了3张图片。快的是2s左右一张，慢的是50s左右一张
2. vtune的日志做了一些处理：
   • 都在加载完模型后才开始采集
   • 都只跑了一张图片
   • 由于快的2s左右一张，怕采集量不够，所以快的循环跑了20次。即放大了20倍。

[luotao1]

@yinghu5

1. uarch 的采集一直没有成功，请问还有别的方式可以判断么？
2. 不用MKL编译，使用OpenBlas编译，两个不同的网络参数，依然差距20多倍。
3. 在网上找到一个类似的帖子：https://stackoverflow.com/questions/38042451/cblas-gemm-time-dependent-on-input-matrix-values-ubuntu-14-04 相同维度的矩阵，如果矩阵中含有0的个数很多，则速度会快非常多

[luotao1]

怀疑和异常数有关系：
@T8T9 当时定位：Res2Net50_26w_4s 和 DPN68 ，网络结构相同，但 conv2d 性能差异较大，是因为动态图得到的模型参数中包含更多的 denormal float value（异常值，如 8.04432e-21），即非常接近于0的值。cpu在计算包含这些denormal value时，性能相比 normal value 会下降 100x 倍（可参考 https://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x 和 https://stackoverflow.com/questions/14001910/what-is-this-denormal-data-about-c ）。解决方法如下：

修复PR为 @Shixiaowei02 PaddlePaddle/Paddle#29924 但这个PR只修复了预测部分，没有动训练。

[yinghu5]

add denormal number documentation:

1. https://software.intel.com/content/www/us/en/develop/documentation/onemkl-linux-developer-guide/top/managing-performance-and-memory/other-tips-and-techniques-to-improve-performance/operating-on-denormals.html

2. https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/floating-point-options/ftz-qftz.html

[yinghu5]

mkl on same function: fast vs slow: 76.26ms vs. 3.84s

[yinghu5]

-msse -mfpmath=sse to GCC and switch the CPU to denormals-are-zero adn flush to zero model

[luotao1]

PaddlePaddle/Paddle#32350 可以解决这个问题，加入后，两个模型的速度基本无差。

[yinghu5]

Perfect resolved!