Do we really need all these 1000 threads running?

Question

Using the fancy new taskmanager in windows 8 i noticed something that for me came as a suprise, the currently used/running threads where around 1k.

Since ive just resonantly touched the tutorials and theory behind multithreading software and games. I got the assumption that if you wanted to get the best performance out of your software, you should always have at least one thread per logical processor when there is work to be done. Since that processor would otherwise be "unused".

But seeing as i am already running around 1000 threads, wont all processors be working on something already?

Why multithread if the processing power is already being used by the other 50 or so processes? Wont managing all these 1000 threads take cpu enough? Why should i as a programmer handle the threads and not the operative system? If it gives each process one thread, wouldn't my software still be "multhithreaded"?.

Is using more threads just a fancier way of prioritizing processes?

Answer 1

I'd say, probably not. Although this question is a bit rhetorical, take a look at this article/book excerpt, by Jeffrey Richter, Stop the madness (from the book CLR via C#). It discusses just those things you ask.

If all we cared about was raw performance, then the optimum number of threads to have on any machine is identical to the number of CPUs on that machine. [...] All threads still have a kernel object, kernel-mode stack, and other resources allocated to them. This trend of creating threads willy-nilly because they are cheap has to stop; threads are not cheap—rather, they are expensive, so use them wisely.

I highly recommend that book. Well worth reading front to back, although it is fairly big, ~900 pages.

Multi-threading though is a very complex subject and cannot be easily answered in just a few lines, it is highly dependent on what you are trying to achieve. As always, it depends and you have to measure/evaluate/optimize any solution to get optimal performance. However, just routinely dishing out threads is probably not a good idea in general. As a side note, a managed thread allocates 1 MB stack memory, meaning that creating (and holding on to) threads in a .NET application can be very wasteful.

Also, just because a tread exists does not mean that it is consuming a full core. It may do some work, but it may also sit idle and wait for some work to come along (which is the most likely case, otherwise your overall CPU consumption would constantly be closer to 100 than 0). They do however consume, or more correct, waste system resources.

Introducing threads adds a significant amount of extra complexity to your application, even though many techniques are being introduced to make them easier to use (various parallel frameworks etc.). The underlying complexity is still there though, sometimes posing as harmless, but always ready to burst out into its true nature (timing issues, deadlocks, debugging complexity etc).

In short you might say, "Do not use multiple thread unless you have a reason to".
Even then, t(h)read lightly.