为啥执行矩阵乘法的两个进程并行运行比连续运行慢？

Posted 2023-02-16

【中文标题】为啥执行矩阵乘法的两个进程并行运行比连续运行慢？

【英文标题】：Why do two processes that perform matrix multiplications run slower in parallel than in succession?为什么执行矩阵乘法的两个进程并行运行比连续运行慢？

【发布时间】：2019-02-12 23:41:31

【问题描述】：

我有一个运行线性代数实验的程序（在 C++ 中使用 Armadillo 库）。我需要多次运行这个程序，所以要并行执行多个进程（取决于我的可用资源）。然而，即使只并行运行两个实验，两个过程也会减慢不成比例的速度 - 它们至少比顺序执行慢 10 倍。

我已经设法将我的代码减少到问题发生的地方，它似乎是我将矩阵乘以向量的地方。这是一个可重现的例子。这将无限运行并打印每 1000 次迭代矩阵乘以向量所经过的秒数。

test.cpp

#include <iostream>
#include <armadillo>
#include <chrono>

using namespace std;
using namespace arma;

int main(int argc, char** argv) 
  chrono::steady_clock::time_point begin = std::chrono::steady_clock::now();

  mat A = randn(1500,1500);
  vec y = randn(1500);
  vec values;

  long its = 0;
  while (true) 

    values = A*y;

    // print time once in a while
    if (++its % 1000 == 0) 
      long secondsElapsed = chrono::duration_cast<chrono::seconds>(chrono::steady_clock::now() - begin).count();
      cout << "secs elapsed by iteration " << its << ": " << secondsElapsed << endl;
    
  
  return 0;

我编译/链接到：

$ g++ test.cpp -larmadillo -std=c++11

当运行该程序的单个进程时，在终端中，输出为：

secs elapsed by iteration 1000: 1
secs elapsed by iteration 2000: 2
secs elapsed by iteration 3000: 3
...

当运行这个程序的两个进程时（在两个不同的终端），进程1的输出是：

secs elapsed by iteration 1000: 24
secs elapsed by iteration 2000: 48
secs elapsed by iteration 3000: 74
...

和进程 2 的输出类似。当第二个进程也在运行时，该进程慢了 24 倍。

Linux 上的“***”实用程序显示两个进程中的每一个进程的 CPU 为 400%，因此总共为 800%（我有 4 个内核 8 个线程）。两个进程分别占用了我 0.3% 的内存。

为什么会发生这种情况，我该如何解决？我不确定如何自己调试，但想学习，所以如果有人可以在他们的答案中提供一些关于如何调试这种情况的提示，那就太好了！

平台详情：Linux 3.10.0-693.11.1.el7.x86_64，4 核/8 线程，8Gb RAM。 g++ (GCC) 4.8.5 20150623 (红帽 4.8.5-36)。 ARMA 版本：8.300.2（热带恶作剧）。

【问题讨论】：

进一步研究的关键字：CPU缓存。

【参考方案1】：

这里有一些事情。

您没有使用优化进行编译。使用-O2 和-march=native

看起来犰狳使用 BLAS 进行向量矩阵乘法。秘密可能就在那里。听起来库已经设置为使用所有内核；您可能无法通过多处理来挤出更多性能。好的...就像您说的那样，您有一个超线程四核 x86_64，并且您想使用 8 个逻辑内核而不是 4 个。但请记住，超线程通过让 2 个线程同时使用处理器来工作.它可以加倍性能，因为通常有很多剩余的算术单元。但是，如果 BLAS 内核在所有 4 个内核上使用所有 SIMD 单元（或者只是很好地利用了可用的算术单元），那么同时运行的第二个实例将不会为自己留下任何硬件，并且可能最终只能进入通过上下文切换的方式，这会弄乱硬件管道并导致缓存未命中。

我正在想办法让您对此进行测试。如果您可以访问具有不同数量物理内核的其他机器，您可能会看到一种模式。一个理想的调试控制是能够告诉 BLAS 使用多少个内核，但我不确定这是否可用。

在这里了解 CPU 架构以及 BLAS 版本（如果您确实在使用 BLAS）会很高兴。

您没有提及您所做的任何分析。如果您还没有完成分析，那么现在将是一个好时机！如果这部分是很多瓶颈，您可以从一些 GPU 加速中受益。或者，如果它是瓶颈，但只是一点点，您可以将程序的其他部分流水线化，以使该部分得到数据。或者，如果运行时间合理，您总是可以满足于当前的速度。