Is there a parallel thread limit equal to the number of processors?

Question

Are there any advantages to limiting the number of simultaneous threads performing a given task in order to equal the number of processors in the host system? Or is it better to simply trust libraries such as .NET ThreadPool, do the right thing ... even if 25 different simultaneous threads happen at any given time?

Answer 1

Most threads are not CPU related; they end up waiting for I / O or other events. If you look at your system now, I think you have 100 (if not 1000) threads running without problems. To this extent, you are probably best left with a .NET thread pool for the right operation!

However, if the threads were connected to the CPU (for example, something like ray tracing), it would be nice to limit the number of threads to the number of cores, otherwise the likelihood that context switching will begin to degrade performance.

Answer 2

The threadpool initiative is already doing a pretty good job of this. It tries to limit the number of running threads to the number of processor cores on your computer. When one thread ends, it immediately schedules another suitable thread for execution.

Every 0.5 seconds it evaluates what happens to the running threads. When threads run for too long, they are assumed to be at a standstill and allow another thread to run. You will now have more threads than processors. This can reach the maximum number of allowed threads, as set by ThreadPool.SetMaxThreads ().

Starting with .NET 2.0 SP1, the maximum number of threads by default has been significantly increased up to 250 times compared to the number of cores. You should never get there. If you did, you would have wasted about 2 minutes of time when a suboptimal number of threads was possible. However, these threads should have been blocked for this long, rather than the typical execution pattern for the thread. On the other hand, if these threads are all waiting on the same resource, they are likely to take turns adding more threads in turn and will not be able to increase throughput.

In short, a thread pool will work well if you run threads that run fast (no more than seconds) and do not block for a long time. You should probably consider creating your own Thread objects when your code doesn't match this pattern.

Answer 3

Well, if your bottleneck is ONLY processors, then this may make sense, but it will ignore all memory and other I / O bottlenecks, and most likely at least your cache throws page errors and other events. which would slow down the flows.

I would trust the library. All kinds of things are waiting for themes, and you don’t want your application to slow down because it cannot spawn a new thread, although most of the others just sleep waiting for some event or resource.

Answer 4

Measure your application in various stream ratios: processor. Come to conclusions based on hard data about your application. Don't accept first-hand arguments about what kind of performance you should get, just what you do.