performance - 最佳进程数？

Question

每个内核的最佳进程数是多少？假设你有一台有 2 个 CPU 和 4 个内核的机器，可以为你提供最佳性能的进程数是多少？

谢谢你的帮助。

Answer 1

答案很自然——这取决于。显然，如果您对某个单线程应用程序的性能感兴趣，其他进程只会使您的机器变得困惑并争夺共享资源。那么让我们看一下这个问题可能很有趣的两种情况:

您正在运行多个进程(假设它们是相同的)，并且您对聚合性能感兴趣。

您正在运行一个多线程应用程序，它可以产生尽可能多的线程。

第二种情况更容易回答，它(.. 等待它..)取决于你正在运行什么!如果你有锁，更多的线程可能会导致更高的争用和冲突。如果您是无锁的(或者甚至是某种免等待的)，您可能仍然会遇到公平问题。它还取决于您的应用程序内部如何平衡工作，或者您的任务调度程序如何工作。今天有太多可能的解决方案。

如果我们假设您的线程之间具有完美的平衡，并且没有增加数量的开销，那么您也许可以将其与其他用例保持一致，即您只需运行多个独立进程。在这种情况下，性能可能有几个最佳点。第一个是当您达到物理内核数量时(在您的情况下为 8，假设每个插槽有 4 个物理内核)。在这一点上，您将现有的硬件饱和到最大。但是，如果您支持某种 SMT 机制(如超线程)，您可以将内核总数增加 2 倍，每个物理内核使用 2 个逻辑内核。这不会在故事中添加任何资源，它只是拆分现有的资源，这可能会对每个进程的执行造成一些惩罚，但另一方面可以同时运行 2 个进程。

总体的聚合加速可能会有所不同，但我在通用基准测试中看到平均高达 30% 的数字。通常，受内存延迟限制或具有复杂控制流的进程可以从中受益，因为当一个线程被阻塞时，内核仍然可以继续运行。更注重执行带宽(如繁重的浮点计算)或内存带宽的代码不会获得那么多。

除了这个进程数之外，在某些情况下添加更多进程可能仍然是有益的——它们不会并行运行，但如果上下文切换的开销不是太高，并且您希望最小化平均等待时间(这它也是一种查看性能的方法，而不是纯粹的 IPC)，或者您依赖于尽早将输出传达出去 - 在某些情况下这很有用。

最后一点 - 如果您的进程在达到该点之前使其他资源饱和，那么“最佳”进程数可能甚至少于核心数。例如，如果每个线程需要一个巨大的块虚拟内存，您可能会开始颠簸页面并将它们分页(痛苦的惩罚)。如果每个线程都有一个反复使用的大型数据集，您可以填满共享缓存，并通过添加更多线程从该点开始丢失。重 IO 也是如此，依此类推。

如您所见，这里没有正确或错误的答案，您只需要在不同系统上对代码进行基准测试。