确定理想的线程数?

这个问题没有简单正确的答案.


这实际上取决于线程是否/是否要等待I/O(磁盘访问，网络等)，以及等待的时间长短与切换线程的成本有关.

如果您的处理器核心只会等待来自RAM的数据，那么处理器不可能比这更快地切换线程.

另一方面，如果线程要等待某个网络连接数据库中的数据，则系统可能能够在等待线程时切换线程并完成一些有用的操作.在这种情况下，拥有两倍于核心的线程可能是有用的.

要考虑的另一件事是，系统中将运行什么(如果有的话)，并且操作系统还会有很多其他事情吗?操作系统如何分配内核? (在这种情况下，结果可能是线程数最好少于内核数.)

最好的办法是尝试各种数量的线程，看看有什么能使您获得最佳性能.我会尝试几个不同的测试用例.如果您有N个核心，则可以尝试使用1线程，N-1线程，N线程，N x 2线程-并观察不断为您带来最佳性能的原因.如果N个线程和N x 2个线程给出相似的好结果，请尝试N x 1.5和N x 3.

There is no easy correct answer to the question.


It really depends on if/whether your threads are ever going to be waiting for i/o (disk access, network, etc.) and how long those waits will be versus the cost of switching threads.

If your processor core is only ever going to be waiting on data from RAM, then it''s unlikely the processor can switch threads faster than that.

If on the other hand, the thread is going to be waiting on data from some network attached database, then the system might be able to switch threads and get something useful done while waiting for it. In that case it might be useful to have twice as many threads as cores.

The other thing to take into account, is what (if anything) else is going to be running in the system, and is the OS going to be a lot of other things? And how does the OS assign cores? (In which case it might turn out that 1 less thread than the number of cores might be best.)

The best thing to do is try various numbers of threads and see what gives you the best performance. I''d try a couple of different test cases. If you have N cores, I''d try 1-thread, N-1 threads, N threads, N x 2 threads -- and see what gave you the best performance consistently. If N threads and N x 2 threads give similarly good results, try N x 1.5 and N x 3.

我遵循一些经验法则，具体取决于应用程序类型.假设N是内核/处理器/单独的CPU执行路径的数量.

如果应用程序是计算绑定的"，即主要是计算周期，则使用N个线程.

如果应用程序是"I/O绑定"的，也就是说，无论I/O速度(磁盘，网络等)如何，它都会花费大部分时间读取或写入数据，然后启动2个线程.

如果应用程序是一些I/O和一些计算的混合，那么它实际上取决于瓶颈在哪里.例如，如果I/O是到/来自远程数据库(SQL等)的，那么许多线程就没有好处.如果I/O是本地的，则最多可以使用N个线程，具体取决于主机缓存/磁盘回写缓存.也就是说，如果主机缓存可以为您带来任何收益，请使用更多线程.

请注意，当使用多个线程时，某些应用程序，甚至是计算绑定的应用程序，都会减慢速度.例如，繁重的CString对象实际上使用瓶颈来等待内存分配/释放，因此在CPU刻录周期期间没有真正的进展.

因此，在向其抛出N，2N或更多线程之前，请了解您的应用程序要求和可能的瓶颈.

I follow a couple of rules of thumb, depending on the application type. Assume N is the number of cores / processors / separate CPU execution paths.

If the application is "compute bound", that is, mostly computation cycles, then use N threads.

If the application is "I/O bound", that is it spends most of its time reading or writing data, regardless of the I/O speed (disks, network, etc), then start 2 threads.

If the application is a mix of some I/O and some computes, then it really depends on where the bottleneck is. For exampls, if the I/O is to / from a remote database (SQL, etc) then there''s no benefit to many threads. If the I/O is local, then you can use up to N threads depending on host cache / disk writeback cache. That is, if host caching buys you anything, use more threads.

Be aware that some applications, even compute bound ones, slow down when multiple threads are used. For example, heavy CString object use actually bottlenecks waiting for memory allocation / deallocation so no real progress is being made while the CPUs burn cycles.

So, know your applications requirements and possible bottlenecks before throwing N, 2N or more threads at it.

这篇好文章是转载于：学新通技术网