CUDA MPI性能瓶颈

Question

我想澄清以下问题。我能够访问包含了Nvidia K40 GPU和Intel Xeon E5 processor.The处理器细节单个节点使用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代码可能无法显示线性缩放（甚至可能因MPI开销和其他因素而减慢速度），因为您将MPI等级计数从1扩展到系统上“处理器”的总数。可以有许多原因，什么都没有做与GPU：

1. 进程放置/亲和力
2. 饱和的CPU
3. 用在HPC代码“超线程”核常节目的内存带宽没有好处或负面影响。

而且我相信还有很多其他的可能性。所以你的性能下降完全可能与GPU没有任何关系（如果它不是瓶颈），并且是由于其他因素造成的。您可以使用分析工具获得最初的想法，上面的链接演示提供了一些想法。