Mark Russinovich clearly explained all the work that has gone into the NT kernel between Vista and Windows 7. For instance, they greatly improved SMP [symmetric multiprocessing] by doing some major work on the dispatcher spin lock, enabling the kernel to scale up to 256 processors. Another one is the cleaning of the core Windows components to eliminate calls that travel up the stack, enabling them to create a relatively bare-bone Windows installation. This installation carries only the most basic functionality (the NT kernel, the executive subsystems, the memory manager, networking, and optional file system drivers), and is referred to as Cutler's NT by Russinovich (or, on the Net, as MinWin). Since there are no upward calls, Microsoft can make changes to these core components without affecting anything higher up the stack -- allowing for easier bug fixing and performance tweaking.
MinWin isn't "done"; the elimination of upward calls is still under way. Microsoft is untangling the intricate web of dependencies inside Windows as to make future changes smoother.
I would call these two elements alone (and there's more, like improvements in the memory manager) definitive and tangible improvements made to the kernel -- and yet, your thread-count statistic doesn't show it. And if your thread-count statistic doesn't reveal even such fairly massive improvements, how reliable and useful of a statistic is it?
That's my point regarding the thread count. The fact that thread count seemed to go up more during previous major releases doesn't prove anything -- it doesn't prove a causal relationship in either direction. You'd need a lot more proof to make me see thread count as an indicator of anything more than just ... the number of threads.
An increase in threads may indicate a performance loss (more complexity). It may indicate a performance gain (optimizing for multicore/SMP). A decrease in threads may indicate a performance gain (less complexity). It may indicate a performance loss ("deoptimization" for multicore/SMP). The statistic alone really, really doesn't mean anything.
Randall to Thom:
Those Win 7 kernel changes have limited real-world effect
Your analogy is still flawed. Code isn't like the surface of an LP. It doesn't degrade over time, nor is there any way to improve its quality without changing it. Which puts us right back at square one: Change the code and you change the tune, which risks destabilizing the whole ensemble.
At this point I think you should probably abandon your LP analogy since it simply doesn't work and you've clearly taken it as far as you can. Or stick with it and I'll keep poking holes. It's your call.
Back to the matter at hand: You claim kernel thread count doesn't matter. I claim it does. I point to historical precedent and benchmark data. You counter with more speculation and then fall back to your flawed analogy.
You know, Thom, just repeating your position over and over again won't make it suddenly become true. You can't invent a major Windows kernel update where none exists. And no, Mark Russinovich's latest interview won't help you. Mark makes it clear that the majority of changes to the shared Windows 7 client/Windows 7 server kernel won't be felt outside of the datacenter. So while it's cool in an academic sense, it has little bearing on the real-world performance characteristics of desktop PCs.