线程数:计算密集型还是IO密集型操作？

Question

我在这个博客上看到了下面的声明

计算密集型操作应该使用低于或等于核数的线程数，而IO密集型操作(如复制文件)对CPU没有使用，因此可以使用更多的线程。

为什么线程数可以大于核心IO密集型操作，而在计算密集型操作情况下应该更低呢？

Answer 1

线程竞争某些资源。如果比可用资源更多的线程需要资源，那么它们只是相互阻塞，而任务切换则会造成开销。问题是，这里涉及的是什么样的资源？

对于CPU绑定线程，资源通常是一个CPU核心。在某些情况下，核心共享某些资源，例如缓存或FPU。特别是，英特尔的超线程常常无助于CPU绑定线程。所以，在你“使用”你的所有核心之前，你可能会停止看到加速。

对于I/O绑定线程，问题是这里涉及的是什么样的精确I/O。如果有争议的资源是硬盘驱动器，那么多个并发访问将减慢速度。如果有争议的资源是网络接口，那么只要不超过接口的总带宽，任何数量的线程都可以访问它而不会出现任何问题。

对于I/O绑定线程，CPU核的数量完全不相关。实际上，您不需要多个线程来执行并行I/O:异步I/O和基于事件的系统在这里是完全足够的。

Answer 2

关于线程数量的处方与应用程序的逻辑无关。在您的应用程序中有更多的线程比内核更多是很有意义的，不管它们是计算绑定还是I/O绑定。

这样做的原因是，当您有更多的计算绑定线程而不是核心时，额外的计算绑定线程将等待，并且不会在它们的计算上取得进展。

考虑使用T=20线程和C=8内核。考虑您的run(要运行的可用线程列表)。最多可以运行8，其余的将坐在队列中等待他们的机会运行。

如果很大一部分线程是I/O绑定的(或者真的阻塞了任何线程)，那么它们无论如何都不会“准备好”运行，也不会影响您的CPU利用率。

如果您认为应用程序的工作是使所有CPU核心保持热(完全运行在100%)，那么在为每个(逻辑)核心至少拥有足够的(计算密集型)线程之后，添加更多的计算密集型线程将不会增加CPU利用率。

注:这是这个理论背后的思想过程(很可能是博主)。这并不完全是真的。在决定如何从处理器中获得最多的计算时，需要考虑更多的因素。一个考虑因素是，让所有的核心运行都会减慢每个核心的运行速度。因此，即使到每个核心都有足够的计算线程为止，增加更多的计算线程也可以使您的速度降低，就像加快速度一样。

在管理线程时有大量的CPU开销(并且可能是内存局部性问题，这取决于您如何分配/管理线程)。

个人的建议/总结--我建议少担心这种推理，多关注应用程序的逻辑结构--什么对它有意义，以及如何让它工作。使用线程池。并使它们的大小可配置。

我的0.02美元。