在并行管道中使用空闲内核？

Question

我一直在阅读this 并行管道教程并注意到，虽然吞吐量肯定存在相当大的差异，但如果压缩阶段也承担读取工作，那岂不是更好，因为它只是反正等着呢？写入阶段也是如此……我的意思是，为什么不进行第三次压缩，然后切换到写入两个，然后让其中一个核心返回压缩，而另一个核心完成第三次写入，然后等等？

如果这很明显，我深表歉意。我想这是标准做法，被称为某种东西，我只是不确定是什么。他们是否会因为这样的换工作而产生任何开销？

而且我知道这可能是最后一个问题的错误论坛，但是 GPU 可以像这样切换工作吗，或者可编程着色器/CUDA 内核在被编程后几乎应该不理会吗？

编辑：我想我也不明白采用 2 核/阶段示例中使用的相同六核如何比只给六个核心中的每一个都提供三个阶段更快。当然，会有两个核心可以做两个，但这仍然比顶级方案更快。在 GPU 的情况下，我会更好地理解它，因为某些计算涉及专门的硬件，但一般来说，我看不到它。也许这个例子很弱或者是什么，因为我知道并行处理会继续存在。

Answer 1

这绝对是流水线的问题，有许多不同的方法可以尝试和缓解它。

使用专用硬件，通常会调整硬件以尝试平衡典型工作负载在每个阶段所花费的时间。例如，GPU 中的固定功能阶段通常围绕代表性游戏渲染工作负载样本的需求进行平衡，并分配晶体管以尝试平衡每个阶段所花费的时间。但是，使用这样的静态平衡通常仍然会浪费一些性能。

一种可用于软件和硬件来平衡流水线的替代方法是将较长的阶段分解为多个较短的步骤。这是 CPU 指令流水线中的常见策略，但在软件中也很有用。在您的示例中，运行时间较长的压缩步骤可能会分解为多个较短的管道阶段。然而，根据任务的不同，这可能很难或不可能有效地完成。

任务调度系统可用于帮助平衡软件管道中 CPU 之间的工作负载。在任务调度系统中，您有许多工作线程（通常每个硬件线程大约一个），并且任何任务都可以在任何工作线程上运行。您有一个 API 来设置任务之间的依赖关系，并且任务调度程序负责调度任务，以便在满足它们的依赖关系后在任何 CPU 时间可用的地方运行。在您的示例中，只要 Compress 任务的 Read 任务依赖关系得到满足，空闲时间运行 Read 和 Write 任务的内核就可以帮助 Compress 任务而不是闲置。

传统的操作系统线程调度程序可以提供与任务调度系统相同的一些好处。在您的示例中，如果读取线程在其工作队列为空时等待信号量（在将新工作添加到队列时发出信号），则操作系统可以安排压缩线程在这些空闲内核上运行。这对于运行时间相对较长的流水线阶段（10 毫秒）可以很好地工作，但对于较短的流水线阶段（不到 1 毫秒），操作系统线程调度的开销和线程时间片的长度可能意味着任务调度系统会提供更好的性能。

Answer 2

您的积分有效。教程不足。

如果读取、压缩和写入操作都可以同时独立进行，那么简单的非流水线情况对于六个内核来说将是最快的。另请注意，在六核图中，读取和写入从不重叠，因此它们可能是相同的。你只需要四个核心。

但是考虑这样一种情况，即所有读取都访问同一个磁盘，因此并行发出太多读取操作会使读取花费更长的时间，因为它们会相互干扰。在这种情况下，您可以通过管道读取来获得收益，因为您更快地开始第一个压缩步骤并且它们限制 整体表现。