如何为hyptherthreading/multicore选择最佳线程数?

我建议你不要自己决定。使用线程池,让.NET为您管理线程。

你可以用 Environment.ProcessorCount 如果那是你唯一想要的。但通常使用线程池确实是更好的选择。

NET线程池还提供了有时分配 更多 在许多线程等待I/O完成的特定场景中,线程比内核多,可以最大限度地提高吞吐量。

正确的数字显然是正确的 42

1) 如果你有很长的时间 可以划分为多个工件的任务(即CPU密集型),然后您应该划分任务,然后将所有单个工作项提交给 ThreadPool . 线程池将拾取工作项并以动态方式开始对其进行搅动,因为它具有自我监控功能,包括根据需要启动新线程,并且可以 configured at deployment by administrators according to the deployment site requirements NUMA nodes ,内存位置和互锁缓存争用,并且仅在这之后才显示核心数)。

2) 如果您正在执行I/O(包括DB调用),那么应该使用异步I/O并在线程池中完成调用,称为完成例程。

这两个是您应该有多个线程的唯一有效原因,使用线程池处理它们都是最好的。在Win32 API世界中,任何其他模式,包括按“请求”或“连接”启动线程,实际上都是反模式(fork在*nix中是有效模式,但在Windows上肯定不是)。

• designing-applications-for-high-performance-part-1.aspx
• designing-applications-for-high-performance-part-ii.aspx
• designing-applications-for-high-performance-part-iii.aspx

最佳数字应该是处理器计数。最佳情况下,您将始终在CPU(逻辑或物理)上运行一个线程,以最小化上下文切换及其带来的开销。

这个数字是否正确取决于(正如大家所说的)你在做什么。线程池(如果我理解正确的话)几乎尝试使用尽可能少的线程,但每次线程阻塞时都会增加一个线程。

阻塞从来都不是最优的,但是如果你正在进行任何形式的阻塞,那么答案将发生巨大的变化。

考虑到您完全受CPU限制,一个好的经验法则是 processorCount+1

+1 n 任务几乎永远不会完全填满 N 处理器。

可能会进行一些自调整,但这将意味着进行某种形式的实时性能调整和自我调整。

甚至比ThreadPool更好,使用TPL中的.NET 4.0任务实例。任务并行库是在.NET 4框架的基础上构建的,它实际上将确定尽可能高效地执行任务的最佳线程数。

我最近读了一些关于这方面的文章(参见 this question 例如)。

简单的答案是由操作系统决定。它能比你更好地决定什么是最优的。

关于一个相似的主题有很多问题-搜索“最佳数量的线程”(不带引号)会给你几页结果。

Environment.ProcessorCount 或者线程池是个好主意。

可以说,选择最佳线程数的真正方法是应用程序对自身进行评测,并根据提供最佳性能的内容自适应地更改其线程行为。

我编写了一个使用多线程的简单数字处理应用程序,发现在我的四核系统上,它在固定时间内用6个线程完成了大部分工作。

我认为唯一真正确定的方法是通过试验或分析。

除了处理器计数外,您可能还希望通过计算GetProcessAffinityMask函数返回的关联掩码中的位来考虑进程的处理器关联性。