Concurrency 用于多核消歧的Cuda流处理

大家好，有几个关于多内核Cuda流处理的问题。

---

假设3.5版开普勒设备中的s流和a内核，其中内核之间的s并发性取决于许多因素，但许多人忽略的一个因素只是内核的大小（即网格中的块数）能够有效利用GPU的内核通常不会在很大程度上同时运行，即使它们能够同时运行，也不会有多少吞吐量优势。GPU内的工作分配器通常会在内核启动后立即开始分配块，因此如果一个内核先启动另一个内核，并且两个内核都有大量块，那么第一个内核通常会占用GPU，直到它几乎完成，在这一点上，第二个内核的块将被调度和执行，可能会有少量的“并发重叠”

主要的一点是，有足够的块来“填满GPU”的内核将阻止其他内核实际执行，除了调度之外，这在compute 3.5设备上没有什么不同。此外，在块级别指定启动参数和统计信息（如寄存器使用情况、共享内存使用情况等）有助于提供清晰的答案，而不仅仅是为整个内核指定几个参数。compute 3.5体系结构在这方面的好处仍然主要来自于“少量”块的“小”内核，它们试图一起执行。Compute3.5在这方面有一些优势

你还应该复习答案

当内核使用的全局内存没有固定时，它会影响数据传输的速度，以及复制和计算重叠的能力，但不会影响两个内核并发执行的能力。然而，对复制和计算重叠的限制可能会扭曲应用程序的行为

不应该有“阅读冲突”，我不知道你的意思。允许两个独立的线程/块/网格读取全局内存中的同一位置。通常，这将在二级缓存级别进行排序。只要我们谈论的是读，就不应该有冲突，也不应该对并发性产生特别的影响

恒定内存是一种有限的资源，在设备上执行的所有内核之间共享（请尝试运行deviceQuery）。如果您没有超过总设备限制，那么唯一的问题将是常量缓存的利用率，以及缓存抖动之类的问题。除了这种次要关系之外，对并发性没有直接影响

确定每个块的共享内存量比确定每个内核的共享内存量更有指导意义。这将直接影响SM上可以调度的块数。但是如果您指定了每个内核的启动配置以及启动调用的相对时间，那么回答这个问题也会更加清晰。如果共享内存恰好是调度中的限制因素，那么您可以将每个SM的总可用共享内存除以每个内核使用的内存量，以了解基于此的可能并发性。我个人的观点是，每个网格中的块数可能是一个更大的问题，除非您的内核每个网格使用10k，但整个网格中只有几个块

我在这里的评论与我对第4条的回答几乎相同。看看您设备的deviceQuery，如果寄存器成为每个SM上调度块的限制因素，那么您可以将每个SM的可用寄存器除以每个内核的寄存器使用率（同样，讨论每个块的寄存器使用率和内核中的块数更有意义）去发现可能的极限

同样，如果您有大小合理的内核（数百或数千个块，或更多），那么工作分配器对块的调度很可能是内核之间并发量的主要因素

编辑：回应问题中发布的新信息。我已经看过kF.png了

首先，让我们从每个SM块的角度进行分析。CC 3.5允许每个SM有16个“打开”或当前计划的块。如果您要启动2个内核，每个内核包含61个块，那么这可能足以填满CC 3.5设备上的“准备就绪”队列。换句话说，GPU一次可以处理其中的两个内核。当其中一个内核的块“耗尽”时，另一个内核由工作分发服务器调度。第一个内核的块在大约总时间的一半内充分“耗尽”，因此下一个内核在前两个内核完成的一半左右得到调度，因此在任何给定点（在时间轴上画一条垂直线），您可以同时执行2个或3个内核。（根据图表，第三次启动的内核与前两次启动的内核重叠了大约50%，我不同意你的说法，即每次连续启动内核之间有3毫秒的距离）。如果我们说在峰值时我们有3个内核被调度（有很多垂直线将与3个内核时间线相交），并且每个内核有大约60个块，那么这大约是180个块。你的K20有13条短信和一条短信。这意味着在峰值时，计划（可能）的块数约为180个，而理论峰值为16*13=208。所以你和max很接近，你能得到的也不多了。但也许你认为你只得到了120/208，我不知道

现在让我们从共享内存的角度来看一看。一个关键问题是您的L1/共享拆分设置是什么？我相信它默认为每个SM 48KB的共享内存，但如果您更改了此设置，这将非常重要。无论如何，根据您的陈述，每个计划的块将使用10KB的共享内存。这意味着w