限制并发线程等于处理器数量？
将执行给定任务的并发线程数限制为等于主机系统上的处理器数有什么好处吗？或者更好的方法是简单地信任 .NET 的 ThreadPool 等库来执行正确的操作...即使在任何给定时刻都有 25 个不同的并发线程发生？
Are there any benefits to limiting the number of concurrent threads doing a given task to equal the number of processors on the host system? Or better to simply trust libraries such as .NET's ThreadPool to do the right thing ... even if there are 25 different concurrent threads happening at any one given moment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
大多数线程不受 CPU 限制，它们最终会等待 IO 或其他事件。如果您现在查看您的系统，我想您有 100 个（如果不是 1000 个）线程正在毫无问题地执行。按照这个标准，您可能最好离开 .NET 线程池来做正确的事情！
但是，如果线程全部受 CPU 限制（例如光线追踪之类的东西），那么最好将线程数量限制为核心数量，否则上下文切换可能会开始损害性能。
Most threads are not CPU bound, they end up waiting on IO or other events. If you look at your system now, I imagine you have 100's (if not 1000's) of threads executing with no problems. By that measure, you're probably best just leaving the .NET thread pool to do the right thing!
However, if the threads were all CPU bound (e.g. something like ray tracing) then it would be a good idea to limit the number of threads to the number of cores, otherwise chances are that context switching will begin to hurt performance.
线程池在这方面已经做得相当不错了。它尝试将运行线程的数量限制为计算机中 CPU 核心的数量。当一个线程结束时，它立即调度另一个符合条件的线程执行。
每 0.5 秒，它就会评估正在运行的线程的情况。当线程运行时间过长时，它会假设它们已停止并允许另一个线程开始执行。您现在运行的线程数将多于 CPU 核心数。这最多可以达到允许的最大线程数，由 ThreadPool.SetMaxThreads() 设置。
从 .NET 2.0 SP1 左右开始，默认的最大线程数大幅增加到内核数的 250 倍。你永远不应该到达那里。如果这样做，您将浪费大约 2 分钟的时间，其中运行的线程数量可能不是最佳的。然而，这些线程都必须阻塞那么长时间，这不完全是线程的典型执行模式。另一方面，如果这些线程都在等待同一类型的资源，它们很可能只是轮流等待，添加更多线程无法提高吞吐量。
长话短说，如果您运行执行速度快（最多几秒）并且不会长时间阻塞的线程，那么线程池将运行良好。当您的代码与该模式不匹配时，您可能应该考虑创建自己的 Thread 对象。
The threadpool already does a reasonably good job at this. It tries to limit the number of running threads to the number of CPU cores in your machine. When one thread ends, it immediately schedules another eligible thread for execution.
Every 0.5 seconds, it evaluates what is going on with the running threads. When the threads have been running too long, it assumes they are stalled and allows another thread to start executing. You'll now have more threads running than you have CPU cores. This can go up to the maximum number of allowed thread, as set by ThreadPool.SetMaxThreads().
Starting around .NET 2.0 SP1, the default maximum number of threads was increased considerably to 250 times the number of cores. You should never ever get there. If you do, you would have wasted about 2 minutes of time where a possibly non-optimal number of threads were running. Those threads however would all have to be blocking for that long, not exactly a typical execution pattern for a thread. On the other hand, if these threads are all waiting on the same kind of resource they are likely to just take turns, adding more threads cannot improve throughput.
Long story short, the thread pool will work well if you run threads that execute quickly (seconds at most) and don't block for a long time. You probably ought to consider creating your own Thread objects when your code doesn't match that pattern.
好吧，如果你的瓶颈只是处理器，那么它可能是有意义的，但这会忽略所有内存和其他 I/O 瓶颈，并且至少你的缓存内存可能会引发页面错误和其他会减慢线程速度的事件。
我自己相信图书馆。线程会等待各种各样的事情，并且您不希望应用程序因为无法生成新线程而减慢速度，即使其余大多数线程只是在休眠，等待某些事件或资源。
Well, if your bottleneck is ONLY processors, then it might make sense, but that would ignore all memory and other i/o bottlenecks, and chances are at least your cache memory is throwing page faults and other events that would slow the threads.
I'd trust the library myself. Threads wait for all kinds of things, and you don't want your application to slow down because it can't spawn a new thread, even though most of the rest are just sleeping, waiting for some event or resource.
在各种线程：处理器比率下测量您的应用程序。根据有关您的应用程序的硬数据得出结论。不要接受关于您应该获得什么表现的首要原则的争论，只有您所做的事情才重要。
Measure your application under a variety of thread:processor ratios. Come to conclusions based on hard data about your application. Accept no arguments from first principles about what performance you should get, only what you do get matters.