Linked by Thom Holwerda on Wed 12th Nov 2008 22:55 UTC
Editorial Yesterday, a story made its rounds across the internet. It was picked up by many large news websites, and I'm sure it will be quoted by people until eternity. It was published by a large website, looked all fancy, it had multiple pages - it looked like it was really something. However, anyone with even the remotest bit of knowledge knows that the article was a collection of complete and utter bogus.
Thread beginning with comment 337166
To read all comments associated with this story, please click here.
Funny thing about threads...
by JonathanBThompson on Thu 13th Nov 2008 01:30 UTC
Member since:

Just because you add or remove threads from a process or a system, doesn't always change performance in a meaningful manner, and it may very well just add more bugs to add them. All other things being equal, it's far easier to create a single-threaded application that works correctly than one with more than one thread, but most GUI processes that have any significant processing that may be done where the user could also conceivably do other tasks while something is running in the background, tend to benefit from at least one more thread. However, there are actually cases in Windows, if they're I/O things you're waiting for, that have no need for adding extra threads to the system: this isn't unique to Windows, granted. But, with asynchronous I/O, things are generally simpler to write and debug than adding another thread just for that purpose. For user applications, the benefits may not be as noticeable, but server applications use this a lot, and in many cases, more threads!= better performance, but rather, more asynchronous I/O calls and a single thread or a small thread pool.

Then there's the generalized case that's not I/O bound, but is instead, largely compute-bound: depending on the task, this may actually noticeably benefit from adding multiple threads, but only enough extra threads to ensure all available processing cores are always busy with useful computations. That being said, once you start adding more threads than that, you're actually going to start losing efficiency, as there's a lot of thread management overhead involved. Here are the basic facts about Windows: most background processes have a rather finite number of threads that make any sense to have, regardless of how many cores are available, because they're mostly I/O bound or waiting for user actions: there's no value added by adding more threads, and it may even be an advantage to reduce some of the threads, and more beneficial, more processes, since switching between processes is more expensive. There really hasn't been that much that's noticeably changed for the things that are done in the background as part of the standard Windows system between Windows 2000 and Vista, and likely no meaningful change between Vista and Windows 7, and chances are, Microsoft figured out the optimum number of threads/processes for each task a long time ago, or perhaps for those that may not be optimum for performance, it was just...easier to not worry about it, and they figured it worked well enough.

Thus, stating "no noticeable thread/process counts means there's nothing that's changed!" (my words) really means nothing of value, because if you're still solving the same basic needs/wants, and they're mostly I/O and/or user-bound instead of compute-bound, there's no incentive to change things very much.

Reply Score: 2