Not a day goes by in which InfoWorld fails to receive a flaming comment or e-mail attacking InfoWorld's Enterprise Desktop blogger Randall C. Kennedy and his recent analysis of the pre-beta version of Windows 7. As time goes on, it gets more personal. Recently, I received this little gem: "Randall C. Kennedy is a jaded, personally hurt, pathological liar who only does a disservice to your Web site."
What could cause such invective? The article that really poked the hornets' nest was "Windows 7 unmasked," in which Randall lays out his argument that Windows 7 is a simply a point rev of Vista. The attacks came fast and furious. How dare Randall benchmark pre-beta software? How could he possibly draw conclusions based on the evidence he presents?
[ Randall C. Kennedy is not gentle with the pre-beta version of Windows 7. Check out his arguments in "Windows 7 unmasked." ]
Several of Randall's detractors have pointed to a critique written by Thom Holwerda, managing editor of OSNews. It was held up as a smackdown and, as it turned out, it was also well written. So what else could we do but invite Thom to debate Randall one on one?
Thom graciously agreed. The ground rules for this e-mail debate were simple. Each message would be of reasonable length. Changes of subject would not be used to circumvent points of disagreement. And both parties would avoid descending into name-calling or profanity. Otherwise, we would not edit the exchange, except to correct spelling or grammatical errors.
I think you'll enjoy the results on the next pages. You'll find more light than heat here, although the discussion is spirited. And while it helps to know something about the inner workings of Windows, both Thom and Randall keep their arguments clear and jargon-free. As Thom says in the final line of the debate: "It's up to the readers to decide which of us is making more sense."
--Eric Knorr, editor-in-chief
Randall to Thom:
The kernel count is in fact a good indicator, if not used in isolation
Thom,
After reviewing your "rebuttal" article, I find that you seem to agree with the core point of my original piece: "In all seriousness, Microsoft has been very clear that when it comes to under the hood, there won't be many changes between Windows Vista and Windows 7. There will be optimizations to improve performance, but nothing drastic."
So, now that we've established that we both agree that Windows 7 is not a major upgrade to Windows Vista (at least as far as "under the hood" is concerned), we can move on to the first major objection in your "rebuttal" text:
"First of all, the number of threads running within a kernel says absolutely nothing whatsoever about how many changes have or have not gone into the kernel ..." (Note: I preserved the emphasis on "whatsoever" from your article.)
Wow! That's a bold statement for someone who (I would assume) does not have access to the Windows 7 source code! The truth is that, without walking the NT kernel source tree, there is simply no way to conclusively make such a statement one way or the other. That's why, in my article, I make a point of establishing the history of this metric and how -- over the 16 years I've been working with the NT code base -- it has proven to be a good, externally accessible indicator of kernel churn.
So my response is: There is no way that either of us can state conclusively that the thread count metric does or does not express change at kernel level. But then again, I never claimed that it does -- only that history shows the value changing significantly from major version to major version. Combined with various statements made by Microsoft on the subject, this lack of change -- when viewed in the context of the aforementioned history for this metric -- would seem to support my own conclusion about Windows 7 being so similar to Vista as to warrant a "point release" or "R2" moniker. A conclusion, I might add, that you have already tacitly agreed to (see first quote above).
Careful with those "absolutes," Thom. You'll find they have a habit of painting you into a corner. :-)
--RCK
Thom to Randall:
It's your method that I believe is flawed. Here's why
Randall,
We do not differ on your conclusions per se, but on the methods and data that you based your conclusions on. I don't know if you could call Windows 7 a major release -- I think that a massively reworked interface and a system-wide multitouch framework that all applications automatically make use of already justifies the "major" moniker, but it's obvious that compared to XP-to-Vista, Vista-to-Windows-7 isn't as long a leap.
The problem is that the "thread count" metric is flawed -- it is flawed today, and it was flawed 10 years ago. I love analogies, and looking around my living room (as I listen to The Police's Zenyatta Mondatta on LP), let's take my LP collection as an example. I don't know the exact count, but I have about 200 LPs. It's a nice collection; mostly old stuff that I inherited from my parents (since I have an LP player and they don't).
Let's assume I'm going on a buying spree tomorrow. I buy 20 new LPs, so now I have 220 LPs. However, I also sifted through my collection, and found 20 LPs that are too scratched to listen to comfortably -- so I throw those out. So, now I'm back to the same old 200 LPs.
Let's say you run LP-Infoworld.com and you monitor the various LP collections in the world. You are standing outside my window, and you counted the number of LPs yesterday, and you do it again after my buying/removing spree. You are standing too far away to notice the specifics of each LP, but your count remains the same: 200. From this, you draw the conclusion that my LP collection is still the same, and that nothing has changed -- despite me buying 20 new ones and throwing out 20 old ones.
It doesn't matter whether this analogy takes place 10 years ago or today. Counting the number of threads, or LPs, doesn't tell you anything whatsoever other than -- surprise -- the number of threads (or LPs) in Windows (or my LP collection).
I never made any absolute claims, as you did in your statement: "Windows 7 = Vista because the number of threads is similar." I don't contest that the number of threads is the same, nor that Windows 7 = Vista. I contest that you arrived at this conclusion based on nothing but counting threads.
--Thom
Randall to Thom:
The kernel count metric is not "empty," and threads aren't interchangeable
Thom,
The flaw in your analogy is that you're assuming you can simply interchange kernel functionality like you can swap LPs -- except that to do so in NT's case would be to irreversibly change the aggregate "tune" of kernel "collection," with the net result that legacy applications and drivers would start breaking all over the place. So any such changes to the collection would have to be extremely subtle so as not to fundamentally alter the "beat." Which is exactly how I'm describing the Windows 7 kernel changes, which were so minor, the Windows core team assigned Windows 7 a point release moniker (i.e., Windows NT 6.1).
To expand on your analogy, any attempt to significantly increase the functionality of the NT kernel would require more than a reshuffling of the LP deck. It would necessitate the introduction of new LPs (threads) to support this expanded capability while maintaining the existing collection mostly intact in order to preserve the original tune (i.e., backward compatibility). Clearly, this has not taken place with Windows 7, but would almost certainly need to take place in any major OS update that continues to support legacy code.
Which brings me to my second point: You're dismissing established precedent. Every major update of the NT kernel has introduced additional threads in support of the new functionality provided. So while thread count may not be conclusive proof that only minor changes have taken place, it's a heck of a good place to start looking. And in the case of my article, that's exactly what it was: An empirical starting point that helped me quickly establish a set of assumptions (i.e., Windows 7 = Vista R2) that I then sought to further qualify through additional analysis and testing.
But I can understand your confusion. To the untrained eye, the kernel thread count metric may seem empty. But to someone who was working with this platform professionally while you were still finger painting in primary school, it says an awful lot. It tells me this is a minor, as opposed to major, update. It tells me that, barring a complete dismissal of legacy compatibility, no significant new functionality has been introduced. And it tells me that any performance optimizations made will deliver, at best, modest gains -- a supposition I later proved during benchmark testing.
BTW, I hope that LP collection of yours includes at least a few classic American bands: Boston, Aerosmith, Led Zeppelin. Maybe a little Tom Petty. Please tell me you're not into techno or some kind of Euro-trash fluff. That stuff's a waste of good rack space. :-(
--RCK
Thom to Randall:
Aha! You fell into my logic trap: Win 7 has better threads, despite the static count
Randall,
My analogy isn't flawed. It's merely designed to be incomplete, so that I could lure you into the trap described below.
Who said anything about interchanging LPs? You assumed interchanging, but I might have bought the exact same worn-out 20 LPs I threw out! I would get better sound, less static, no skipping … my world wouldn't change and turn pink with ponies and rainbows all of a sudden, no, but I would get a much more pleasurable listening experience.
And counting my LPs still wouldn't reveal those improvements.
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.
--Thom
Randall to Thom:
Those Win 7 kernel changes have limited real-world effect
Thom,
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.
Since this line of discussion is clearly going nowhere, I suggest we switch gears and focus on another area you touched on in your rebuttal article: benchmarking.
In your article you say, and I quote: "Vista was a dog when it was first released, but these days, after lots of patches, fixes, and a service pack, it's actually quite snappy."
My challenge: Prove it.