我想澄清以下问题。我可以访问包含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的内容，但我认为在这种情况下它没有多大用处，因为它更适用于多节点情况。如果我错了，请纠正我。有哪些可能的方法可以改善这些情况下的表现？
答案 0 :(得分：3)
是因为内核对GPU的访问是序列化的吗？
GPU上的序列化可能会以某种方式对您正在观察的内容做出贡献，除非您采取特殊步骤。 MPI创建了许多进程。一种常见的策略是为每个CPU核心创建一个进程。来自不同进程（针对单个GPU）的CUDA活动通常会在该GPU上进行序列化。
在这些情况下，有哪些可能的方法可以改善效果？
CUDA MPS专门针对这种情况而设计。它允许从单独进程发出的GPU活动表现得好像它们都来自同一进程。这可以具有几种类型的效率优势（例如，GPU上没有上下文切换，同时运行某些GPU内核的可能性等），但我不想夸大该功能。在您的情况下它是否以及对它有多大帮助只能通过尝试来确定。
如果你在GPU上投入大量工作（按照MPI等级），那么当然期望任意线性缩放是不合理的。一旦GPU完成工作，如果GPU成为瓶颈，事情将不会更快，并且额外的MPI等级服务的额外开销实际上也可能减慢速度。
从幻灯片40开始，This presentation在这种情况下提供了许多有关MPS的有用信息。
请注意，我主要关注GPU方面。通常，当您将MPI排名计数从1扩展到系统上“处理器”的总数时，MPI代码可能不会显示线性缩放（甚至可能由于MPI开销和其他因素而减慢）。这可能有很多原因与GPU无关：
我相信还有很多其他的可能性。因此，完全有可能您的性能下降实际上与GPU无关（如果事实证明它不是瓶颈）并且是由于其他因素造成的。您可以使用分析工具初步了解这一点，上面链接的演示文稿提供了一些想法。