c++ - 我是否正在使用OpenMP干扰其他程序？

Question

我正在将OpenMP用于这样的循环:

#pragma omp parallel for
for (int out = 1; out <= matrix.rows; out++)
{
    ...
}

我正在具有64个CPU的计算机上进行大量计算。这相当不错，但我的问题是:
我在打扰这台机器上的其他用户吗？通常他们只运行单线程程序。他们还会继续使用100％吗？显然，我会打扰其他多线程程序，但是会打扰单线程程序吗？
如果是，我可以预防吗？我认为可以使用 omp_set_num_threads设置最大CPU数。我可以将其设置为60，但是我认为这不是最好的解决方案。
理想的解决方案不会打扰其他任何单线程程序，而要占用尽可能多的CPU。

Answer 1

每个多任务OS都有一个称为进程调度程序的东西。这是一个OS组件，它决定在何处以及何时运行每个进程。调度程序通常在做出的决策中非常固执，但是这些决策通常可能会受到用户提供的各种策略和提示的影响。几乎所有调度程序的默认配置都是尝试将负载分散到所有可用的CPU上，这通常会导致进程从一个CPU迁移到另一个CPU。幸运的是，除“最先进的桌面操作系统”(又称OS X)外，任何现代操作系统都支持称为处理器亲缘关系的东西。每个进程都有一组允许在其上执行的处理器-该进程的所谓CPU相似性集。通过为各种进程配置不相交的相似性集，可以使那些并发性亲缘关系集并发执行，而不会彼此浪费CPU时间。在Linux，FreeBSD(带有ULE调度程序)，Windows NT(这也包括Windows XP之后的所有桌面版本)以及可能的其他OS(但不包括OS X)上，支持显式CPU亲和力。然后，每个操作系统都提供了一组内核调用来操纵亲和性，并且提供了一种无需编写特殊程序即可执行此操作的工具。在Linux上，这是使用sched_setaffinity(2)系统调用和taskset命令行工具完成的。亲和力也可以通过创建cpuset实例来控制。在Windows上，使用SetProcessAffinityMask()和/或SetThreadAffinityMask()，可以从任务管理器的上下文菜单中为给定进程设置亲和力。启动新进程时，也可以将所需的亲和性掩码指定为START shell命令的参数。

所有这些与OpenMP的关系是，所列操作系统的大多数OpenMP运行时都以一种形式或另一种方式来支持，以便为每个OpenMP线程指定所需的CPU亲和力。最简单的控件是OMP_PROC_BIND环境变量。这是一个简单的开关-设置为TRUE时，它指示OpenMP运行时“绑定(bind)”每个线程，即为它提供仅包含单个CPU的相似性集。线程到CPU的实际放置取决于实现，每个实现都提供了自己的控制方式。例如，GNU OpenMP运行时(libgomp)读取 GOMP_CPU_AFFINITY 环境变量，而Intel OpenMP运行时(不久前为开源)读取 KMP_AFFINITY 环境变量。

这样做的理由是，您可以限制程序的亲和力，使其仅使用所有可用CPU的子集。然后，其余进程将主要安排在其余的CPU上，尽管只有在手动设置它们的亲和力后才能保证(这只有在具有root / Administrator访问权限的情况下才可行，因为否则，您只能修改那些您拥有)。

值得一提的是，与亲和性集中的CPU数量相比，使用更多线程来运行(但并非总是如此)是没有道理的。例如，如果将程序限制为在60个CPU上运行，则使用64个线程将导致某些CPU被超额预订，并且导致线程之间的时间共享。这将使某些线程的运行速度比其他线程慢。大多数OpenMP运行时的默认调度是schedule(static)，因此并行区域的总执行时间由最慢线程的执行时间确定。如果一个线程与另一个线程分时共享，那么两个线程的执行速度将比那些不分时的线程执行得慢，并且整个并行区域都会被延迟。这不仅会降低并行性能，而且还会导致周期浪费，因为更快的线程会简单地等待什么都不做(可能在并行区域末尾的隐式屏障处忙于循环)。解决方案是使用动态调度，即:

#pragma omp parallel for schedule(dynamic,chunk_size)
for (int out = 1; out <= matrix.rows; out++)
{
    ...
}

其中 chunk_size是每个线程获得的迭代块的大小。整个迭代空间分为 chunk_size迭代块，并以先到先得的方式分配给工作线程。块大小是重要的参数。如果它太低(默认值为1)，则OpenMP运行时管理动态调度可能会产生巨大的开销。如果它太高，则每个线程可能没有足够的可用工作。块大小大于 maxtrix.rows / #threads毫无意义。

动态调度使您的程序能够适应可用的CPU资源，即使它们不是统一的，例如如果还有其他进程正在运行并且与当前进程分时共享。但这有一个问题:像您的64核这样的大型系统通常是ccNUMA(与高速缓存相关的非均匀内存访问)系统，这意味着每个CPU都有自己的内存块，并且可以访问以下内存块:其他CPU则比较昂贵(例如，花费更多时间和/或提供更少的带宽)。动态调度会破坏数据的局部性，因为不能确定驻留在一个NUMA上的内存块不会被在另一个NUMA节点上运行的线程利用。当数据集很大并且不适合CPU缓存时，这一点尤其重要。因此，YMMV。