CUDA MPI性能瓶颈

我想澄清以下问题。我可以访问包含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，但我认为它在这种情况下没有多大用处，因为它更适用于多节点情况。如果我错了，请纠正我。在这种情况下，有哪些可能的方法可以提高绩效

是因为内核对GPU的访问被序列化了吗

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

在这种情况下，有哪些可能的方法可以提高绩效

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

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

，从第40张幻灯片开始，提供了许多关于此场景中MPS的有用信息

注意，这里我主要关注GPU方面。通常，当您将MPI列组计数从1扩展到系统上的“处理器”总数时，MPI代码可能不会显示线性扩展（甚至可能会由于MPI开销和其他因素而减慢）。可能有许多与GPU无关的原因：

进程放置/关联

使CPU的内存带宽饱和

在HPC代码中使用“超线程”内核通常没有任何好处或负面影响

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