限制并发线程等于处理器数量？

Question

将执行给定任务的并发线程数限制为等于主机系统上的处理器数量有什么好处？或者更好的是简单地信任像.NET的ThreadPool这样的库来做正确的事情......即使在任何一个给定的时刻发生了25个不同的并发线程？

Answer 1

大多数线程不受CPU限制，它们最终等待IO或其他事件。如果你现在看一下你的系统，我想你有100个（如果不是1000个）线程执行没有问题。通过这个衡量标准，你可能最好离开.NET线程池来做正确的事情！

但是，如果线程都是CPU绑定的（例如光线跟踪之类的东西），那么将线程数限制为内核数量是个好主意，否则上下文切换可能会开始影响性能。

Answer 2

线程池已经在这方面做得相当不错。它会尝试将正在运行的线程数限制为计算机中的CPU核心数。当一个线程结束时，它会立即安排另一个符合条件的线程执行。

每0.5秒，它会评估正在运行的线程的运行情况。当线程运行时间太长时，它会假定它们已经停止并允许另一个线程开始执行。现在，您运行的线程数比CPU核心数多。这可以达到ThreadPool.SetMaxThreads（）设置的最大允许线程数。

从.NET 2.0 SP1开始，默认的最大线程数大大增加到核心数的250倍。你永远不应该到那儿。如果这样做，您将浪费大约2分钟的时间来运行可能非最佳数量的线程。然而，这些线程都必须在那么长时间内阻塞，而不是线程的典型执行模式。另一方面，如果这些线程都在等待相同类型的资源，它们可能只是轮流，那么添加更多线程无法提高吞吐量。

简而言之，如果您运行快速执行的线程（最多几秒）并且不会长时间阻塞，则线程池将运行良好。当代码与该模式不匹配时，您可能应该考虑创建自己的Thread对象。

Answer 3

好吧，如果你的瓶颈只是处理器，那么它可能有意义，但这会忽略所有内存和其他i / o瓶颈，并且可能至少你的缓存内存会导致页面错误和其他会减慢处理器的事件线程。

我自己信任图书馆。线程等待各种各样的事情，你不希望你的应用程序变慢，因为它不会产生一个新的线程，即使其余大部分只是在休眠，等待一些事件或资源。

Answer 4

在各种线程：处理器比率下测量您的应用程序。根据您的应用程序的硬数据得出结论。不接受关于你应该获得什么样的表现的第一原则的论据，只接受你做的事情。