posted by Thom Holwerda on Tue 2nd Dec 2008 10:58 UTC

Thom
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 as well 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 suddenly 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 7. For instance, they greatly improved SMP 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 of 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 (and there's more, like improvements in the memory manager) alone 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 much of a reliable and useful 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 (optimising for multicore/SMP). A decrease in threads may indicate a performance gain (less complexity). It may indicate a performance loss ('deoptimisation' for multicore/SMP). The statistic alone really, really doesn't mean anything.

Thom

Table of contents
  1. Randall, opening
  2. Thom
  3. Randall
  4. Thom
  5. Randall
  6. Thom
  7. Randall
  8. Thom
  9. Randall
  10. Thom, final
e p (0)    78 Comment(s)

Technology White Papers

See More