每个核心的最佳进程数是多少？假设您拥有一台拥有2个CPU和4个核心的机器，那么为您提供最佳性能的流程数量是多少？
感谢您的帮助。
答案 0 :(得分：3)
答案很自然 - 这取决于。显然，如果您对某个单线程应用程序的性能感兴趣，其他进程只会使您的计算机混乱并在共享资源上竞争。那么让我们看看这个问题可能有趣的两个案例：
第二种情况更容易回答，它（等待它......）取决于你正在运行的东西！如果您有锁，更多线程可能会导致更高的争用和冲突。如果你没有锁定（甚至是某种无等待的），你可能仍然存在公平问题。它还取决于应用程序内部工作的平衡方式，或者任务调度程序的工作方式。今天有太多可能的解决方案。
如果我们假设您在线程之间有完美的平衡，并且没有增加数量的开销，那么您可以将其与您只需运行多个独立进程的其他用例对齐。在这种情况下，表现可能有几个甜点。第一种是当你达到物理内核的数量时（在你的情况下为8，假设每个插槽有4个物理内核）。此时，您将现有的硬件饱和到最大值。但是，如果您支持某些SMT机制（如超线程），则可以使用每个物理核心2个逻辑核心将核心总数扩展2倍。这不会在故事中添加任何资源，它只会拆分现有的资源，这可能会对每个进程的执行造成一定的损失，但另一方面可以同时运行2个进程。
整体总体加速可能会有所不同，但我看到通用基准测试的平均数量高达30％。作为一个整体，内存延迟限制或具有复杂控制流的进程可以从中受益，因为当一个线程被阻塞时核心仍然可以进展。更加面向执行带宽（如重浮点计算）或内存带宽的代码不会获得那么多。
除了这些进程之外，在某些情况下添加更多进程可能仍然是有益的 - 它们不会并行运行，但如果上下文切换的开销不是太高，并且您希望最小化平均等待时间时间（它也是一种看待非纯IPC性能的方式），或者你依赖于尽早传达输出 - 有些情况下这很有用。
最后一点 - 如果您的流程在到达该点之前使其他资源饱和，则“最佳”流程数可能甚至小于核心数。例如，如果每个线程需要一个巨大的块虚拟内存，您可能会开始捶打页面并将其分页（痛苦的惩罚）。如果每个线程都有一个大量使用的数据集，那么您可以填充共享缓存并通过添加更多线程从该点开始丢失。重IO也是如此，等等。
正如您所看到的，这里没有正确或错误的答案，您只需要在不同系统上对代码进行基准测试。