Linked by Thom Holwerda on Tue 2nd Dec 2008 10:58 UTC
Windows Two weeks ago, I published an article in which I explained what was wrong about Randall Kennedy's "Windows 7 Unmasked" article. This was noted by Infoworld's editor-in-chief Eric Knorr, who suggested that Randall and I enter into an email debate regarding the various points made in our articles. We agreed upon publishing this email thread as-is, unedited (I didn't even fix the spelling errors), on both Infoworld and OSNews. We agreed that Randall would start the debate, and that I had the final word. Read on for the entertaining email debate (I figured it would be best to give each email its own page, for clarity's sake. My apologies if this makes each individual page much shorter than what you're used to from OSNews).
Thread beginning with comment 339043
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by DeadFishMan
by DeadFishMan on Wed 3rd Dec 2008 11:04 UTC in reply to "RE: Comment by DeadFishMan"
Member since:

" Mark Russinovitch is a god among men when it comes to Windows development and I will always listen what that man has to say but now that he is on the MS payroll, his comments should be taken with a grain of salt as they can be slightly biased towards his employer, naturally.

He's a god among men in much the same way as Stargate:SG1 has the G'ould as gods amongst their slaves: he convinces them that they (the slaves) are inferior to them, and that they (the G'ould, not sure of spelling) are all-powerful and correct, and must do their bidding, all while being horribly mortal and flawed, despite all the technological hocus-pocus-steal-the-focus underpinnings.

That this twit developer could ever state MDAC is in the kernel is at least as amazing as stating that thread count changes matter all that much, which goes to demonstrate that he's not done any real server-based development, or anything where threadpools are used, which... these days is likely to be just about anything, if factored correctly. Sorry, developing things similar to MS Paint does not make you qualified to judge how many changes in a kernel have resulted as measured by the dubious test of number of total threads ;)

You realize that you're talking about the guy from SysInternals, right? The one that made tools that even Microsoft Support Engineers used during their troubleshooting (which I can attest as true given that I worked as a Microsoft Enterprise Technical Router for almost 02 years and saw that happening on a daily basis)? And that this is the same guy that uncovered the inner workings of the infamous Sony rootkit not that long ago?

Are we talking about the same Mark Russinovich? ;)

Reply Parent Score: 2

JonathanBThompson Member since:

That makes it even more puzzling why he'd write such stupid things for two things, then, as I have that book myself. But, I'll note it doesn't go into server programming, which is a common usage scenario of threadpools that I have experience in.

Many other posters have mentioned about optimization of threadcount (or not) and how little it really can be for how it changes the overall code, or how major code changes don't change the threadcount at all, and this is something born out from experience, too: it just is meaningless without more information, information that can't be observed from Task Manager or the equivalent by itself. If you run a system that uses multiple threads awaiting things to do on a massively SMP system, it makes sense to actually have some reasonable number of threads more than there are cores to process them, as you want to keep all cores busy, if there's actually work to do. However, if that same code is running on a single core or light SMP system, where there's not enough CPU power to keep everything going at full tilt, and I/O is the major issue, asynchronous I/O is the way to go, as well as optionally using a threadpool, depending on the application and what's measured in real use. Otherwise, you'll be using a heck of a lot of scheduling time and task switching overhead that's completely wasted, preventing the system from accomplishing real work.

So, to sum it up:
If there's more computational work than a number of cores can do, adding threads just slows things down.

If there's more work with lots of I/O that keeps I/O busy, not using asynchronous I/O (Windows and Linux and many Unix have it: use it!) will needlessly add more threads that... don't do any useful work.

If there's lots of computational duties and there's more cores available than there's likely to be tasks of any length available to do, have at least as many threads as there are cores within that process, and still, measure if using a threadpool system helps: you want to keep all hardware busy, but in a useful manner, and thread and task switching with synchronization objects just gets more expensive when you add more cores, due to hardware cache synchronization, cache flushing, etc. so it still pays to only have as many threads as you can have actively doing useful work all the time. Along with thread switching time, each time you add a thread, there's a stack memory requirement, and you can quickly eat through a lot of RAM that way, and address space in general, though granted, that's not nearly as much of an issue when going to 64 bits. Oh, and the more threads you have that you don't need, the more of a bitch it is to debug ;)

Reply Parent Score: 2