Thom,
</p>
<p>
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 fundamentally alter
the "beat." Which is exactly how I'm describing the Windows 7 kernel
changes: So minor as to not merit more than the point release moniker that
the Windows core team assigned it (i.e. Windows NT 6.1).
</p>
<p>
To expand on your analogy, any attempt to significantly increase the
functionality of the NT kernel would require more than a re-shuffling 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. backwards
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.
</p>
<p>
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") which I
then sought to further qualify through additional analysis and testing.
</p>
<p>
But I can understand your confusion. To the untrained eye, the kernel
thread count metric may seem "empty." But to someone who's been working with
this platform professionally since 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-out during benchmark testing.
</p>
<p>
BTW, I hope that LP collection of yours includes at least a few classic
American bands. Boston. Aerosmith. Led Zepplin. 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. :-(
</p>
<p>
RCK
As a software developer I am fully agree from the functionality that kernel thread count means a new functionality. Windows have a huge legacy and every subsystem that exists will have an impact on performance. Adding new subsystems to Windows will increase the thread count, so adding any functionality/services, major revamp to Windows will introduce new threads. Optimizations in algorithms and fixes will not justify enough to increase the version number.
Thom seems for me wrong (again as a devel) because the services of Windows cannot be removed without making some other to complain.
Thom shows anyway a logic that may be possible in Linux for instance (that’s why it scales from mobile phones to super-computers) that you can remove functionality from kernel as much as you need to fit on your machine.
Probably the Windows Server 2008+1 will have the possibility to strip down the installations and the kernel, but I think is unlikely that persons wants to deploy one OS that will not give to you the guarantee that all you had yesterday you cannot run tomorrow.
Randall have right as much it knows the back of the development of NT kernel. Changing the policy of developing the NT kernel may lead that the thread measure is not right, but for now is really valid.
Windows Vista = Windows 6.0
Windows Seven = 6.1
Optimizations and fixes do justify a minor revision.
Well a whole new UI that makes you work better and faster and more productive, plus touch functionality and gestures and massive productivity improvements and ease of use and entirely of new toolbar functionality and a new graphics improvements and API’s such as directx 11/direct 2D and a new way to render text are pretty big things.
I didn’t even mention the improved UI speed and overall performance improvement.
Redesigning existing services could also increase the thread count.
There’s no cause-and-effect relationship between increase in thread count and new features. It just so happens that sometimes a new feature will increase the thread count.
Really? and you say this as a developer? Scary.
Unless you happen to know what microsofts policies for kernel development is there’s no way you can know this fort sure.
Have you ever implemented anything that uses a pool of worker threads?
I can imagine Microsoft employees reading this and thinking that instead of actually doing any work they’ll just change a “fooBarWorkerThreadCount” registry setting, and then call it Windows 8. I wonder how many people would see the dramatic increase in the thread count and decide there must be a corresponding massive number of new features…
I have to agree with you entirely. Thread count bares no relationship to new functionality whatsoever.
Recently I re-wrote some monitoring software from single threaded to multi-threaded. The threads were worker threads. There’s an option in the software to adjust the size of the worker thread pool, so at any time without a single change of code I can increase this pool with zero new functionality.
You must not be a good developer then. Windows Vista does not have a lot in the Kernel. Most of everything lives outside the kernel.
You might want to educate yourself:
channel9.msdn.com
Sure, having access to source is useful. But without source, one can download windbg, attach the kernel debugger to a machine (or VM) running the version of Windows we’re looking at, and dump the threads. Doing so with public symbols will still give you a stack trace, and a reasonable clue of what those threads actually do.
From there, you can see what has changed between Vista & Win7, or at least get a better idea than a thread count.
So, in the area that I work, we removed one reserved thread in order to support new functionality in Win7 that we couldn’t support by having a single, system-wide thread for this particular task. It didn’t break apps, or any exposed functionality; it merely reworked how the code operated (and made it somewhat more scalable for good measure.)
For MinWin, just to be clear – MinWin is a refactoring effort. It doesn’t have much to do with the kernel. Most changes are usermode. The most significant part, IMO, is breaking kernel32.dll up between kernelbase.dll (low level routines) and kernel32.dll (higher level routines.) If you do “dir c:\windows\system32\kernel*” on Win7, and see kernelbase.dll, that’s MinWin. And before anyone asks, kernel32.dll/kernelbase.dll are not kernel components.
But I’ll end this with a plea. I’m an OS enthusiast, as are many readers here, and this kind of finger-pointing debate isn’t really providing us with much useful news or information. There are good OS topics to debate all day, but the debate needs to focus on technical issues, not who-said-what-first or who-was-fingerpainting-when. Please – debate technology (and dig deep to find it!), not personalities. Be careful with “you”/”I”/”me”; these are not technical terms, and frequently do not add to technical discussion.
Edited 2008-12-02 12:22 UTC
Well,not quite a dialog. It seems that one person knows what is talking (with arguments) and that’s Randal while the other one is just filling the screen with words to match up the word count Randall’s emails have. And that’s Thom. Euphemistic, it’s a discussion between a professional (Randall) and a hobbyist (I was about to say dilettante).
The professional doesn’t know about thread pools. Mid way through a development cycle, (build 6801 is not even a beta), you are not going to be doing things like optimizing the thread pool size, so of course the count is going to be the same.
My guess is the “professional” wrote a line of business app that used some sort of parallelism, and now considers himself a domain expert. Both his assertion that thread pool size is a good indicator of feature count on a kernel mid way through its dev cycle, and a bunch of other things he said in his article (like how MDAC is in the kernel) shows a real lack of understanding on how windows works.
I don’t pretend to understand kernel development, but I do have a high level understanding of MDAC and worker pools, enough to know that what he is saying is just silly.
When people use phrases like ‘mid way though a development cycle’ and ‘not even a beta’ it’s because they know nothing has changed but they are insinuating that something will change later on. Using the “Oh we don’t know what will happen” argument is just daft.
You don’t go mucking around with kernel thread handling and integrity when you start releasing public builds the last I checked, especially when you have stated that drivers and applications will be completely compatible with a previous kernel version. This doesn’t just mean binary compatibility, because you have to account for timing and all sorts of other extreme quirks.
In the absence of source code then we either go on hearsay as to what has changed, or someone looks at some evidence as to what has changed.
MDAC as in Microsoft Data Access Components…..?
In what way? Unless you affect fundamental changes to something that impact on developers, and possibly users, then there is very little change you can have beyond limited bug fixes in Windows – and even then, somebody might start depending on the bugs that exist in a previous version! It has happened before. On top of this, we have a kernel that will allow existing binary Vista drivers to work, which places even more restrictions on it.
That’s the way Windows works, and nothing will change that. Restrictions == no change, and the limited evidence bears that out. Sorry, but “They said in this blog post that this has changed” isn’t a rebuttal.
http://en.wikipedia.org/wiki/Thread_pool_pattern
That sort of stuff you mess with when you need to, or when you are optimizing. You do not optimize for a build you give out to developers at the PDC.
Whether or not the thread count changes is irrelivent. What is relevant is that it has changed in previous windows releases. This is a preview build, not a release, so once again, the thread count fades into irrelevance. The fact that you are arguing this shows you know next to nothing about windows memory management. I am far from an expert, but I know enough to be able to say the guy is full of crap.
from the article
I do not understand how anyone can take this guy seriously. Did you even read the article?
May his points be valid or not – what was up with Randall harping on about music styles? Really, that seemed kind of cheap. I’m glad that Thom didn’t get provoked by that, but stuck to a rational conversation instead.
mightshade wrote:
–“May his points be valid or not – what was up with Randall harping on about music styles? Really, that seemed kind of cheap.”
I think it was some sort of Jedi mind trick, right after Randall mentioned Boston I dug up and started playing ‘Peace of mind’ and from that moment on I was on his side no matter what.
I haven’t read the whole debate yet, but the stuff about actually benchmarking makes all kinds of sense to me as it provides actual data to debate, not someone’s subjective ‘personal experience’. And no, I don’t think youtube videos counts.
Agreed, I don’t think RCK was being very professional. Whether he has valid points or not–I personally think they both do–I couldn’t help but cringe when I saw some of his responses. i think that says something about RCK’s character, if not necessarily his knowledge and technical proficiency. For the record: music styles have nothing to do with Windows 7, and firing off personal attacks at your challenger doesn’t decrease *their* credibility, it decreases *yours*. In this case, I think RCK was doing more to hurt his own credibility than Thom’s.
I think it’s funnier that he tried browbeating Thom with Boston, Aerosmith, Led Zepplin, and Tom Petty. If you’re going to do that, at least have good taste in music.
(You know Television, Kraftwerk, Devo, The Misfits w/Glenn Danzig, The Stooges.)
Actually, I think he was being flippant. The way I read them, the comments on music style were intended to introduce some light-hearted banter into an otherwise heavy-weight debate.
20 minutes of my life I can never get back.. but hey, it was entertaining.
I tend to agree that thread count (based on historical precendent) is a decent metric of, at the very least, how “heavy” an OS is, and if Windows 7 has the same thread count as Vista then I have very little hope for a clean, responsive OS coming from Redmond.
Offtopic: Thom, putting Vista on a netbook is crazy talk. Vista is too complex and brings no significant benefits. I just installed Windows 2000 on my eeepc and it’s running like a well oiled machine. It makes me happy. I still maintain that windows 2000 represents Microsoft’s finest hour, and that if they really wanted to capture that market, they should make a prettier skin for windows 2000, bring the driver base up-to-date with contemporary netbook hardware, re-open support for security patches, and call it Windows Netbook edition. Now THAT would sell!
Edited 2008-12-02 12:26 UTC
I disagree. XP x64 is the best. Then is Windows 2000.
Damn, if thread count is a decent way of judging how ‘heavy’ an OS is, then BeOS must look like a bloated whale. Ever looked at how many system threads are running on that mofo? It puts windows to SHAME.
(not really, but it just goes to show thread counts don’t really help show how heavy an OS is, imo.)
Such a shame that what could have been a really good to and fro of debate decended into a sniping match
Both had sound points, yet instead of debating them started making personal attacks
I think both sides lost marks in my eyes because of this
Just because you shout loudest does not make you right
OH YES IT DOES!!!
Seriously though, Thom seems to take a more philosophical point of view by dismissing the thread count metric simply because it’s not 100% reliable.
This seems to me like seeing two guys wrestle, one weighing 100 pounds and the other weighing 300 pounds, then claiming both have a 50% chance to win the fight.
Just because there are invisible factors doesn’t mean we should throw up our hands and say “Let’s just trust the marketing material!”.
We should still take the visible indicators into account while keeping in mind that there might be other factors.
Overall I’d say Randall won the argument but lost some of my respect because of his lack of self control. Thom sounded a bit like a broken record but at least stayed friendly.
To have a real debate you must listen to two sides of the argument. Even (especially?) if you don’t agree with it
There were times when it seemed that both stopped listening and simply started shouting louder.
That was when the ‘debate’ began to fall apart
it became fun reading but was no longer ‘informative’
This debate reminds me of a scene from an absurdist play I saw a few years back (The Bald Soprano).
A husband and wife are sitting in their living room when the doorbell rings. There’s no one at the door when they open it, and this happens twice more. After the third time, the husband proclaims “You see, when the doorbell rings, there is never anyone there.”
Then the doorbell rings a 4th time – and this time there is actually someone at the door. So the wife triumphantly proclaims “You see, when the doorbell rings, there is always someone there!”
Great. 🙂 Oh how I love allquantified expressions – fail of proof with only one counter-example, and then claim the complete opposite of the expression.
From Randall, opening: Careful with those “absolutes,” Thom. You’ll find they have a habit of painting you into a corner. 🙂
The more forceful something is claimed, it can be counter-argumented very easily when not backed up with enough facts (that are more useful than individual opinions in such kind of debate).
Or to mangle an old expression, “All absolutes are inherently false – including this one.”
Wow, so many inaccuracies, so little time. However, RCK was the one that wrote that ADO runs in kernel space so, well, that’s credibility out the window already.
I’d like to say that I read all of this but once the “my music taste is better than yours” topic came up I just gave up. Euro-trash? Is that the counterpart of “awesome” “American” music like Britney Spears, 50-cent and Pussycat Dolls?
I find it amusing that someone who make claims of having been around a long time thinks that Led Zeppelin is an American band.
Edited 2008-12-02 13:33 UTC
And Aeorsmith? I’ve never really been able to see them as “classic rock” – more like a mediocre Rolling Stones knock-off for people who find George Thoroughgood “too high-brow.”
I think that Randall’s remarks about music styles were light-hearted and intended to be taken as jokes, so I see no harm there and Thom never responded to those so he probably dismissed them, as he should. Having said that, I happen to share his musical taste and indeed would recommend that stuff to Thom if he hasn’t checked it out yet.
I also agree that the increasing count of threads despite they claiming that they are just refactoring code must be an indication that something is not quite right over there so I think that Randall’s original point remains. 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.
But the thing that surprised me the most was Thom claiming that he is running Vista on a netbook (no less!) comfortably. Vista IS a dog and no matter what people say, no matter how many performance improvements it got since RTM, it is still slow as molasses without adding any perceivable benefit over XP. I have a pretty fast laptop that does run Vista reasonably well but given the hardware specs, I would be expecting something much better performance wise (and yes, I am up to date with patches) so I can’t imagine what would lead someone to do that on a netbook!
Yes, Thom kept the conversation civil all the time and Randall was way out of line sometimes but I will side with him still…
Trust me, it works wonderfully. I am using my Vista-powered EeePC 1000h to type this.
trust me people can be comfortable in most displeasant situation.
I mean that all this comfort notion is very subjective.
but anyway.
In a subjective view vista is a dog. And make dev life more difficult (when before they could go with a “run the application as admin”), is a space hog, give the user less and less control over data on the hard drive.
Yet the kernel seem fine,　the side by side save seem to be running ok and allow the user some install mistake.
do windows need a clean slate, god no that would a hudge mistake, win32 is still a good userland api despite its bugginess, and the kernel is still unbloated enough to be relevant. However microsoft need to rework the services, Windows is hosting more and more service process that doesn’t help neither the speed ( or percieved speed), and os clarity .
Well said sir. I was going to mod you up but apparently I made a post already…
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?
http://en.wikipedia.org/wiki/Mark_Russinovich
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
It was like reading a debate between politicians and it was about as interesting.
So Randall accuses Thom on a couple of occasions of being a Windows fanboy:[quote]But then again, you’re not really a journalist, are you Thom? You’re more of a fan boy who somehow managed to secure himself a bully pulpit from which to spout his unsubstantiated blather.[/quote]That’s news to me, and goes a long way in establishing credibility, or (as in this case) the lack thereof.
I thought both of them have good points about thread counts. I have at times made huge changes to the code I’ve written, with huge improvements to efficiency (better algorithms) without changing significantly the outward appearance of the code. I’m hardly the only developer to experience this gratifying phenomenon (sorting algorithms, anyone?). It seems to me that Thom is arguing that this is the general approach of Windows 7.
If that’s true, and if Randall is really saying (as he appears to be saying) that this implies there are no real changes that improve functionality, user experience, etc., then Randall is sticking to an appallingly poor choice of words. The rest of his arguments attack straw men more or less: all are valid and insightful points, but they have nothing to do with Thom’s original statement.
Exactly – it sounds like he’s just whipping out the tired old chestnut of “You’re just saying that because of [pre-supposed bias goes here] – which is incredibly convenient, because it lets me dismiss your argument without the hassle of writing an actual rebuttal.” The only difference is that that sort of nonsense is usually confined to an article’s comments, not the article itself.
The hell of it is that I agree with Randall’s conclusion, but I think the argument he bases his conclusion on is absurd. He’s basically making an unverified assumption that is, itself, based upon “post hoc, ergo proctor hoc” reasoning – an assumption based on a fallacy, great.
And the further hell of it? It would be trivially-easy to actually verify his conclusion – and do so using something a little more substantial than the number of kernel threads (like, say, the names, numbers, and relative sizes of system files between Vista and Win7).
Well, you know what they say about IT journalist; they’re the guys who cant cut it in the field.
Intersting that on the whole, OSNews readers seem to basically agree with Kennedy.
Infoworld readers seems to favor Thom.
http://www.infoworld.com/article/08/12/02/49FE-windows-7-great-deba…
The whole thing makes me think of power plants. If you were a power plant expert for the first half of the century, you’d notice a correlation between CO2 output and power produced at plants. Then The first Nuclear plant would be built and some industry stooge would declare that its an incredibly weak power plant, based on the C02 output.
I can’t believe Thom never hit on a similar metaphor. Editor position, please!
You’re hired.
Seriously now, that’s a really good analogy, and really sums up my position perfectly. I could basically replace the entire ten emails about thread count with just this analogy.
Too bad I didn’t think of it.
Even more interestingly, in the original post I got the feeling that osnews readers generally agreed with Tom while now it’s the other way ’round.
It seems that the readers of that site already dislike the editor, thus are more inclined to take the opinion of the fresh face with higher regard.
Same thing is happening here, with roles reversed. It is interesting.
I’m a OSN reader and I still think that measuring development by counting threads is absolutely bogus. I don’t care about historical precedent, entire subsystems could be overhauled while retaining a similar thread count. Even more, let’s say they optimize something and then decide to remove useless threads: can we say that they have actually removed functionality?
Well, I’m with Thom on this one. Changes in thread count is just an indicator of… changes in thread count.
Randall may have some historical evidence to give his argument some credence, but ultimately his entire argument is fallacious: one of correlation vs causation and historical fallacies.
Perhaps in the past, changes in thread count have accompanied significant changes in the kernel. But a stronger argument is needed to establish causality.
(However, I do tend agree with Randall’s assessment of Rock > Techno, but there’s no accounting for taste
)
Of course, rock > techno, but it’s all irrelevant.
Fiona Apple > everything.
Well I do agree rock > techno
But house/progressive > rock
Pretty much everything is better than techno.. Techno is really only one step above pop as far as being completely meaningless tripe
BTW, thom won this hands down. The other guy pretty much spent the entire time flailing around trying to change the subject, and throwing out personal attacks when he couldn’t come up with an argument.
Edited 2008-12-02 21:26 UTC
The whole thing was pointless, and Randall’s arguments looked pointless, because Thom argued back about nothing.
Apparently, we are all supposed to throw away any evidence at all that we can find in an OS that anything has changed, and we are all supposed to believe in some pink pony hearsay about SMP and memory management improvements of the kind that people get in every minor Linux kernel update to see whether major changes have occurred. It doesn’t make the whole a major new OS though.
The question is, do we look within the OS and the kernel for any evidence that we can that things have actually changed, or do we use hearsay from PDCs and blogs about improvements people say have happened? Anybody who believes the latter has taken leave of their senses. Fallacious doesn’t quite cut it, and alas, using hearsay has never disproved, or proved, a thing.
I would like to thank you, Thom, for trying to keep the debate civil. Randall took every opportunity to launch both subtle and not so subtle personal attacks. Personal attacks are almost always the sign of someone who has already lost the argument, but does not want to admit it.
Your last rebuttal, though, did get a bit personal. Anyway, all in all you did a much better job of sticking to the debate than Randall did. And as an American I have to say he was off the mark in his references about the music.
For those who want to skip the boring stuff, or who couldn’t make it all the way through, it gets juicy half way down page nine.
I like the way this Randall chap kept citing his own credentials to support his argument. He was kind of making sense until he went all ad hominem. Just a pity you had to join in Thom, especially seeing as you had the last word. It’s possible that the comparison to John Dvorak was fair but calling his writing bullshit was unnecessary. Up ’til then, I think you’d won on penalties.
I found the whole conversation to be utterly pointless. I found Randall’s e-mails to be pesky, tiresome and obnoxious. This is not how a knowledgeable fella should formulate his point of view over a topic. Also, I found his references to music styles to be out of line. As the references to his 20+ years of history. Which, proves just as much [or as nothing] as the thread counts.
This has all just been a waste of time.
I see Randall is still pushing those benchmark results he collected some time ago to get the 40% number.
If I understand things correctly (I haven’t installed that stuff, but I’ve read a little about what’s in it), his benchmark drives the UI at superhuman speeds and finds that it performs 40% slower. This has nothing to do with the Kernel as such and everything to do with the way GDI acceleration has changed (gone away!) in Vista. While GDI lives in the kernel address space (win32k.sys), it’s hardly a kernel subsystem and MinWin can run without it.
I guess businesses should stay with XP… if they employ amazing robots who can type, scroll, and insert charts simultaneously at a rate of several operations per second. Frankly, desktop applications (even “Enterprise” ones) do not stress the kernel’s performance characteristics that much since the bottlenecks are usually elsewhere. One exception is the apps that have huge datasets, like CAD/CAM. Win7’s memory manager improvements are specifically targetted at these scenarios.
I don’t know what is more insane, that he went and made these blog posts expecting to be taken seriously, or that people are actually taking him seriously.
This is irrefutable proof the internet is full of morons.
That’s the harsh truth I’m afraid. No one is going to look at their existing applications and say “Yay, we can run them 40% slower!” No one cares that Microsoft has borked GDI, although you might.
Contradiction in terms. I’d call that a kernel subsystem if it’s in there, but there seems to be a lot of delusion about what is or isn’t in a kernel these days.
Yay. Let’s run no applications.
He, he, he. Yer. That’s why they have computers and these things called ‘applications’ that can do nifty things like scripting to do all that for them at a faster rate every eighteen months or something. Or did I miss something?
Bottom line: It’s still slower, no matter where you believe the bottlenecks to be.
Let me get this straight: You script the UI of your applications to get work done quickly? Maybe that’s good for a quick-n-dirty system (I’ve made a few of these with Excel and VBA), but most ‘real’ scripting environments don’t really involve a whole lot of GDI drawing.
My question is: Thom, why did you ever enter a debate with someone stating that he could judge a kernel by number of its threads? It’s like saying that a coconut palm and a pine are the same tree because they have the same number of leaves…
This was too easy for you: we know you could fight harder battles 😉
I really can’t understand why someone who said a blatant bs is willing to turn this into a widespread debate and look even more childish…
Because he didn’t say that at all, although Thom thought he did and got fixated on it. He used thread count as one metric in a series of articles to judge, based on past Windows releases and history, just how much upheaval the Windows 7 kernel (amongst other elements of Windows 7) was going to be for everyone and how much overall change had occurred.
The answers were none and an indeterminate and insignificant amount that could not be verified other than through hearsay.
Edited 2008-12-03 00:38 UTC
Counting kernel threads is not an acceptable metric. Even when that’s simply a fraction of the whole analysis.
I cannot take as serious someone stating that, I’m sorry. Let alone someone tracking kernel threads on Windows as history (or worse, proof) of his statements.
And by saying that, we’re not stating that those kernels are different: we’re just saying that you cannot tell by counting threads.
I’m among those who think that Windows kernel doesn’t need a rewriting: that’s not the point where Microsoft should improve as first priority. Nevertheless, a rewrite which cut ties to other components upward the stack and keeps the kernel serviceable per se, for sure is a good work and it’s worth the pain. And justifies a new version because you won’t be able to rewrite kernel that way without changing much inside the OS itself.
I’m not a fan of these academic debates but if we really need to do that, it’s better to do that using real facts and not a simplistic approach.
Needs a vote box. Thom vs Randall.
Am I the only one noticing that when Thom posted links to several benchmarks supposedly proving that Vista had significantly improved in performance compared to RTM, at least one of the benchmark actually supported Randall?
Looking at page 6 of the anandtech benchmarks http://www.anandtech.com/systems/showdoc.aspx?i=3233&p=6 , there’s almost no difference between SP1 and RTM except for maybe 7% difference in the PCmark Vantage score.
While perhaps he was right on a lot of points, he comes across as a real tool, at least in this “debate”. Too bad he couldn’t take the high road and keep it professional.
While thread counting makes for an interesting starting point to see the potential weight of the OS, it is merely a starting point and nothing more. In depth analysis will tell you why the thread count is what it is or why there is a change in thread count if any at all. But there mere presence, increase, decrease, or sameness is only a starting point of investigation and an interesting statistic in the end.
While I found comments regarding music to be … uhmm … tasteless, I thought that comments about “pink ponies and rainbows” was downright rude. Therefore on the ethics side of the debate Randall gets: -1 and Thom: -3.
On the matter of general logical principles, Randall gets: 1 and Thom gets: 3.
On the matter of properly evaluating an OS, Thom gets: 3 and Randall gets: 4
Overall this debate was in the lines of: I say “tomato” you say “tomaato”
I read that, and wish I hadn’t. A lot of lengths have been gone to so that Thom, in his own little fantasy world, can prove that he is not wrong…….again.
I know Thom has had a bee in his bonnet, and he gets rather upset (how upset he gets is a clue to reality), when anyone suggests that Windows 7 is merely a totally cosmetic facelift to Vista to make 7 what Vista should have been outwardly to start off with. Everything in Windows 7, from drivers to the very limited amounts of software written for Vista, will be compatible with Vista. It deserves a version bump, but you’ll have to go a long way to the right to find a minor version number it does deserve bumping.
Thom then gets hung up on some thread count kernel argument, which was merely one metric used that has been a guide in the past. Given that Windows 7 will run Vista’s drivers without any modification whatsoever, then Windows 7 must use the same kernel with mere cosmetic modifications and compatible bug fixes because even subtle changes alter behaviour in lots of unexpected ways. You can’t risk that. If Thom doesn’t know that then he doesn’t know what he’s talking about………..again. Logically, this must be the case.
All the SMP and memory improvements are meaningless. They are bug fixes and some feature improvements (most of them having been backported from Windows 2008!), neither users or developers will notice and such changes deserve the moniker of a very minor version bump.
Oh, and what on Earth was the LP analogy about? Whew.
Laughably, Thom then brings up MinWin (a microkernel if you please), where we have established that MinWin is just an NT kernel that has not been altered or even ‘stripped down’ in any way, nor is there any justification for the description. As I’ve said before, we get this lunacy around every new version of Windows where everything is positioned as a break from the past and things have been reinvented. They just plain haven’t.
MinWin is currently vapourware as it was presented. It might turn out to be a rather amusing way for Microsoft to better bootstrap and install from a Live CD, or something, that we’ve all been using forever, but right now it amounts to nothing but PDC hype. For compatibility reasons, there are serious question marks over what form it can exist in. It really isn’t that great and it bears no relation in reality to how it was described in OSNews articles. No, really. All that hype for some DLL rearranging which is what MinWin really is?
Sorry Thom, but bug fixes to make things actually work as they were intended does not mean a new OS. That’s what this is really about. If you keep at this, padded walls are beckoning for you.
Less of the day: When you sign off with the ‘personal attacks’ retort, you’ve lost.
“[Thom] gets rather upset (how upset he gets is a clue to reality), when anyone suggests that Windows 7 is merely a totally cosmetic facelift to Vista to make 7 what Vista should have been outwardly to start off with.”
What in all Hades are you talking about?! That Windows 7 is internally -not- a significant change over Vista has been Thom’s position the -entire- time.
Since I seem to be Mr Logical Fallacy, I will point out the one in your post. It’s called ‘straw man’, and frankly, I find it one of the most insulting.
Its weird he calls thom upset, but has racked up tons of threads (pun intended) being upset himself. State your point and exit, no need to beat the horse over and over again, and be the one your so critical of.
Both had valid points, whatever, though I tend to side with Thom in this case – number of threads doesn’t tell you anything about what the threads do – or how well they are written.
On the other hand you can use the statistic to make questionable assumptions, resulting in some “possibly correct” conclusions.
At the end of the day you still dont know really whats going on… Neither of them used dev tools to inspect the threads, Maybe in that case you could figure it out.
Randall also came over as a bit of a pompous dick.
“Listen to some good classic American rock”, “not euro blah blah”…
Im guessing Randall is American? – Learn to be a bit diplomatic when interviewing someone from another country.
Aside from that, it seems a lot of speculation, which has limited value.
Edited 2008-12-03 04:44 UTC
Never do analogies. It has no purpose but to stupidify the person you are talking to.
Well rewriting a core system can certainly cause performance bottlenecks that have to be retuned to get the missing performance back (see recent CFS and HPET Linux tbench regression, or the known IP stack and Vista MMCS issue).
Vista was of course released prematurely and many of those problems were left unsolved, causing mostly latency and throughoutput issues which people (and most benchmarks) perceive as a lack of performance. Even a little bit of retuning existing codebase could make W7 seem noticeably faster.
What, IMO, they seem to do with MinWin is just proper layerisation of “hybrid” (userspace) parts of kernel as it’s an ugly mess that traverses IPC calls up and down and nobody probably only a few people understand how it works precisely. I guess this refactoring can possibly affect performance in both ways, improve it or make it worse, and might need a new retuning – I hope they do it for W7. Unfortunately Windows source code is a closely guarded secret so we can just speculate what they are doing and why.
People calling for a full rewrite of core parts of the system are just nuts. It took ages to design the thing and even if it is ugly mess, improving the same code pays off in a better way.
This article/flame is more of a “Dvorak” than the starting issue alltogether, as i see it =)
About the issue:
Does total thread count reflects changes occurred in the kernel?
Not necessarily. I am with Thom on this point.
Does thread count might suggest an incremental version?
Reasonably yes. As a metric per se however, it’s totally irrelevant.
Stop filling da int4rw3b ktnx ;D
REPEAT AFTER ME:
It just doesn’t matter. It just doesn’t matter. It just doesn’t matter.
How many hours of your lives were devoted to this pointless debate?
May I direct your attention to the following XKCD comic?
http://xkcd.com/386/
I side with Thom in this, not that my opinion matters in the slightest. It wasn’t as entertaining a read as any of Jack Thompson’s email conversations with various journalists.
To be honest….this Randall character comes off real poorly, as if “who are you to question me?” type of BS. But at the end of the day, this discourse was pointless as both Thom and Randy are arguing (debating) ALPHA code. Thom, I think, acknowledges that fact. It’s Randy, that seems to think the PDC demo is going RTM next week.
In Thom’s defense, Randall committed the first gaffe with his very public ‘Windows 7 ain’t nuthin but a gussied up Vista re-tread’ FUD after looking at running threads and services in an alpha product. Who, and at what time, ever said that Windows 7 was going to be based on ANYTHING other than Vista’s code-base?
Anyway, if this Randall guy were anyone else posting his “findings” on this board, he’d be labeled a troll, and dismissed quickly. I like how he so fervently went with the ‘fan-boy’ accusation. Score one for objectivity, cupcake.
And on an unrelated note, Zeppelin was good….but all they did was rewrite other people’s songs.
I didn’t go through 8 pages of comments, so perhaps somebody else mentioned this already, but thread *count* says absolutely nothing about performance. Most of the time, threads do absolutely *nothing*. More threads certainly mean more complexity (since they need to interact), but as long as they are blocked waiting for whatever, they do no harm (but consume memory, which of course may affect performance, but in a different way). (Also, I’m pretty sure the heavily multi-threaded BeOS has much more threads than its contemporary Windows versions (NT4, 2000), but was quite a bit leaner and better performing.)
As for the e-mail debate, I found it disappointing Thom didn’t want to mention his favourite music, but I really hope those 200 LPs aren’t techno, as he inherited them from his parents
. On a more serious note, I don’t think either of the opponents had very strong points, nor were they very convincing debaters.
JAL