Is Windows ready for dual core? Or is dual Core ready for Windows?

Hey guys, I found an excellent article which addresses some concerns people might have with dual core processors. While it does not use heavy technical jargon, it should explain quite clearly the effect of using a dual core processor with Windows---besides the obvious fact that it's much, much faster

http://searchwincomputing.techtarget.com/tip/0,289483,sid68_gci1248527,00.html?track=NL-473&ad=581919&asrc=EM_NLT_1193051&uid=5838498

 

Nice short article, Gator.

Just out of curiosity, why would Windows OSes be multi-threaded before the advent of dual core procs? I assume that when the author, Posey, says

does he mean that even before dual core, Windows was multi-threaded??

 

Well, before multicore processors we had SMT, and I believe multi-proccesor x86 systems have been around since Pentium Pro or thereabouts. There were also Windows NT ports to other architectures early on. I'm pretty sure there was one for Alpha, and maybe one for PPC? I'm not nearly as familiar with the history of those platforms, though, so I don't know when they first offered SMP. I know PPC has had SMT for quite a bit longer than x86.

Then you have to remember that the NT kernel and OS was originally meant for workstations and servers, where a DOS based system was just laughable. SMP was much more common in these environments, and it was an absolute requirement that it was supported by the kernel.

 

Because even on a single-core machine it can have advantages.
In cases where individual tasks may be blocked for a long time (say, waiting for harddrive reads), it's convenient to have multiple threads, so that the remaining threads can still use the CPU while the blocked thread is idling. If you had only one thread, valuable CPU time would be wasted.

And of course, it gives the illusion that things are able to be executed in parallel, which is *very* nice for the end user. (MS Word's spell-checker would be a good example)

Also for some purposes, multithreading makes programming easier. (not always, and in many cases it can be a major pain, but still, if you want to run two independent tasks belonging to the same process in parallel, multithreading is your friend).

I'd put more emphasis on multi-processing though. Windows has always (or at least, since Win95) used dozens of processes to do all the tasks that need doing. The purpose is pretty much the same as with threads, except processes are better separated so you don't get all the multithreading bugs and headaches. In an OS that gives pretty much the same benefits (simulating parallel execution, multiple processes to take advantage of spare CPU time when one is being held up, ability to use multiple cores, and the ability to program different tasks separately. And probably most importantly, the ability to multitask, and run multiple programs simultaneously... Wouldn't be much of an OS without that.

And as said above, the NT kernel was made for several architectures, and multicore systems (or other forms of SMT) has always been necessary to support.

 

We had multi-processor computers ever since Celerons.
But for servers, the Multi-processor concern and theory is much older.(The #Lock and #release instructions were added for this purpose to 286 CPU)
And in the server scale,multi-processing was always and option for providers who desperately needed more processing power to meet the demands.
And Windows's Quasi-Micro kernel also required multi-threading.(Multi-threading is supported via the protected mode)

 

Yep, as said above it's to avoid the long wait times a user would suffer in single threaded OS's, because the PC has a limited number of resources that would otherwise not be shared amongst different programs running on the OS.

As implied, this is for single core processors only. In dual core processors, there is true parallel processing, which means that programs can in fact be run simultaneously and not flip-flop back and forth on one CPU through context switching.

 

I just read that article. He has no clue what he's talking about, specifically because of this sentence:

Which is crap. It takes VERY little overall time to assign cores to threads. It's not insignificant time, but it's nowhere near half the CPU's time. What blocks is I/O, and other tasks. You can't have two threads getting access to different parts of the hard drive at the same time, or different memory, etc. Windows MAY have inefficient (and often) kernel-mode context switches, but that happens on single-core systems too, so it's a red herring. THAT is where most of the performance issues come in, not in thread switching.

 

multi proc is nothing new. Multi proc on one chip is what is new. Back in the pre gighertz days dual PII and Dual Athlon MPs were fairly common as workstations and servers. Though they generally had seperate ram interfaces. The idea that applications are not written for multi-cores is well, stupid. I have several that are multicore aware. Sonar 6 even lets me see how much of each core I am using while I am using it.