CUDA MPI 性能瓶颈

Question

我想澄清以下问题。我可以访问包含 Nvidia K40 GPU 和 Intel Xeon E5 处理器的单个节点。使用 lscpu 命令获得的处理器详细信息如下：

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                32
On-line CPU(s) list:   0-31
Thread(s) per core:    1
Core(s) per socket:    8
Socket(s):             4
NUMA node(s):          4
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 62
Stepping:              4
CPU MHz:               2300.201
BogoMIPS:              4599.40
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              16384K
NUMA node0 CPU(s):     0-7
NUMA node1 CPU(s):     8-15
NUMA node2 CPU(s):     16-23
NUMA node3 CPU(s):     24-31

我正在运行一个 MPI 程序，它将工作分配给处理器的 32 个内核。然后每个内核将一部分卸载到 GPU。在运行代码时，性能会降低（执行时间增加）而不是降低？是不是因为内核对 GPU 的访问被序列化了？我只想了解这个概念，因此我没有发布任何代码。我已经阅读了有关 CUDA 感知 MPI 的信息，但我认为它在这种情况下并没有多大用处，因为它更适用于多节点情况。如果我错了，请纠正我。在这种情况下有哪些可能的方法来提高性能？

Answer 1

是不是因为核心对GPU的访问被序列化了？

GPU 上的序列化可能会以某种方式影响您所观察到的情况，除非您采取了特殊步骤。 MPI 创建了许多进程。一种常见的策略是为每个 CPU 内核创建一个进程。来自不同进程（针对单个 GPU）的 CUDA 活动通常会在该 GPU 上进行序列化。

在这种情况下提高性能的可能方法是什么？

CUDA MPS 专为这种情况而设计。它允许来自不同进程的 GPU 活动表现得好像它们都来自同一个进程。这可以具有几种类型的效率优势（例如，GPU 上没有上下文切换，可以同时运行一些 GPU 内核等），但我不想过度推销该功能。它对您的情况是否有帮助以及有多大帮助只能通过尝试来确定。

如果您在 GPU 上投入大量工作（每个 MPI 等级），那么期望任意线性缩放当然是不合理的。一旦 GPU 的工作饱和，如果 GPU 成为瓶颈，事情就不会变得更快，而且额外的 MPI 等级服务的额外开销实际上也可能会减慢速度。

This presentation，从幻灯片 40 左右开始，提供了有关此场景中 MPS 的大量有用信息。

请注意，我在这里主要关注 GPU 方面。通常，当您将 MPI 排名计数从 1 缩放到系统上的“处理器”总数时，MPI 代码可能不会显示线性缩放（甚至可能会因为 MPI 开销和其他因素而变慢）。这可能有很多与 GPU 无关的原因：

1. 进程放置/关联
2. CPU 内存带宽饱和
3. 在 HPC 代码中使用“超线程”内核通常没有任何好处或负面影响。

我相信还有很多其他的可能性。因此，您的性能下降完全有可能实际上与 GPU 无关（如果事实证明它不是瓶颈）并且是由于其他一些因素造成的。您可以使用分析工具初步了解这一点，上面链接的演示文稿提供了一些想法。