Performance 在运行多个进程时缓解共享库瓶颈

我正在使用2个Intel 6230（总共40个核）的2插槽主板进行基准测试。计算机正在运行RHEL-7.6并使用NUMA。我的最终目标是确定在Intel机器上使用Intel的MKL库与在AMD机器上使用Intel的MKL库之间的性能差异

我使用Anaconda安装了

python-3.7.3

。查看

numpy

的共享库：

ldd /home/user/local/python/3.7/lib/python3.7/site-packages/numpy/linalg/lapack_lite.cpython-37m-x86_64-linux-gnu.so
    linux-vdso.so.1 =>  (0x00002aaaaaacc000)
    libmkl_rt.so => /home/user/local/python/3.7/lib/python3.7/site-packages/numpy/linalg/../../../../libmkl_rt.so (0x00002aaaaaccf000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab3b6000)
    libc.so.6 => /lib64/libc.so.6 (0x00002aaaab5d2000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab995000)
    /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)

您可以看到它取决于

libmkl\u rt.so

。大概像

np.dot（）

这样的线性代数例程依赖于此。因此，我运行以下代码，

numpy\u test.py

：

import numpy as np
matrixSize = 5000     # outer dim of mats to run on
N = 50       # num of trials 
np.random.seed(42)
Ax = matrixSize
Ay = 10000
Bx = 10000
By = matrixSize
A=np.random.rand(Ax,Ay)
B=np.random.rand(Bx,By)
npStartTime = time.time()
for i in range(N):
    AB = np.dot(A,B)
print("Run time : {:.4f} s".format((time.time() - npStartTime)))

用一个内核运行这个程序（错误，见下文）大约需要17.5秒。如果我同时在所有40个核上运行它，每个进程的平均运行时间是1200秒。这试图为缓解此问题提供解决方案。其中两个可能的解决方案甚至不起作用，第三个选项（

dplace

）对于RHEL 7.6似乎不容易访问

问题

当运行40个进程时，巨大的性能损失是由于所有进程都在竞争访问共享库（大概是

libmkl\u rt.so

），而共享库只存在于内存中的一个位置，这是否合理

如果是真的，是否有现代的解决方案来强制每个核心使用其自己的共享库副本？我似乎找不到一个静态版本的

libmkl\u rt.so

来构建

numpy

编辑

根据Gennady.F.Intel的建议，我运行：

$ export MKL_VERBOSE=1; python3 src/numpy_attempt.py
Numpy + Intel(R) MKL: THREADING LAYER: (null)
Numpy + Intel(R) MKL: setting Intel(R) MKL to use INTEL OpenMP runtime
Numpy + Intel(R) MKL: preloading libiomp5.so runtime
MKL_VERBOSE Intel(R) MKL 2019.0 Update 4 Product build 20190411 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) with support of Vector Neural Network Instructions enabled processors, Lnx 2.10GHz lp64 intel_thread
MKL_VERBOSE SDOT(2,0x555555c71cc0,1,0x555555c71cc0,1) 2.58ms CNR:OFF Dyn:1 FastMM:1 TID:0  NThr:40
MKL_VERBOSE DGEMM(N,N,5000,5000,10000,0x7fffffffc870,0x2aaad834b040,5000,0x2aaac05d2040,10000,0x7fffffffc878,0x2aaaf00c4040,5000) 370.98ms CNR:OFF Dyn:1 FastMM:1 TID:0  NThr:40
.
. 

---

因此，我认为对资源的争夺更多地与以下事实有关：我的40个实例中的每一个都要求40个线程，总共1600个线程。如果我

export MKL_NUM_THREADS=1

并运行我的40个

numpy_test.py

实例，平均运行时间约为440秒。在计算机上运行

numpy\u test.py

的单个实例需要240秒。我认为差异已经得到了解释，但问题尚未得到回答。

您是否可以通过设置“export mkl_VERBOSE=1”环境变量来尝试查看mkl将返回什么？非常好的建议。请参见上面的编辑。它解决了大量的运行时差异，但没有说明问题的答案。是的，这是典型的线程超额订阅问题，MKL只有一个解决方案，只使用1个线程运行代码，但您已经找到了这个解决方案。