Slashdot Mirror
Next Windows To Get Multicore Redesign
eldavojohn writes "A Microsoft executive announced that the next Windows will be fundamentally redesigned to handle the numerous cores of present and future processors. The article notes that the NT technology underneath Vista has been able to take advantage of multiple processors since 1993, and can now handle 32 or 64 cores. And since Microsoft completely rewrote the 20-year-old GDI/GDI+ model for Vista, what more can (or should) they parallelize? It will be interesting to see how Microsoft tackles the race conditions and deadlocks that come with pervasively multithreaded software and in the past complicated attempts (like that of BeOS) to utilize multiple CPUs. Do you think it's it a smart move to further complicate an operating system to take advantage of multiple cores, or should Microsoft stick to its knitting while applications take advantage of (possibly) more resources?"
Anyway, no need to redesign, just fix what they already have.
With computers going multi-core, it's only natural for MS to also move in that direction. As many will not doubt point out, MS does need to do a lot of work as their single core OS is still very lacking.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Imagine a beowulf clusterfuck of these.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
Well, I don't even see the troll vote on his moderation anymore and my message got modded off-topic. Like I said, I'll never understand the way moderation works around here.
As for kill task working fine, it works fine for me most but not all of the time. Sometimes a process gets well and truly bjorked and the system never recovers. Explorer 7 likes to crash a lot, especially with multiple windows open. Mozilla isn't much better about stability but the "restore session" feature is awesome. It will even preserve edits in text boxes if it goes down while you're in a form. In other words, that feature makes the pain of instability a whole lot less. Kudos for them.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
I'll never understand slashdot moderation.
Me either. Accurate moderation would have been "-1, Wrong" or "-1, Ignorant".
Well, I've been writing multithreaded apps since around 1997 (unlike Jeremy Reimer the arstechnica 'author of derivative drivel articles', who wrote a "HISTORY OF THE GUI", yet has never written an application himself, much less a multithreaded/multicore aware one - more on his lack of expertise on this subject in my closing P.S. below) & here are my thoughts based on experience:
Background: I started out mostly in Borland Delphi (2.0 - 7.0), & lately, more in ASP.NET/VB.NET, & here are my thoughts on this subject:
"but all the apps have to become multi-core aware." - by Bullfish (858648) on Thursday May 31, @09:41AM (#19336277)
Great idea in principal, but not that easy @ times. I will give an example of where it is most difficult imo @ least, & why (finding things that lend themselves to this in code and the process & data the code works on), here goes:
It's NOT that simple, because some tasks are processed in a linear nature, so for instance (in Delphi using CreateThread (TThread encapsulates this in Delphi native instruction code)), this does not always lend itself to greater performance, especially when 1 operation depends on the results of another!
E.G. #1 (of linear processing that does not gain by the use of separate threads on each calculation) in 'fine-grained multithreading':
Summation = A+B
EndResult = Summation x 2
There is no point in putting "Summation's calculation" onto a separate thread, along with putting "EndResult's calculation" onto another separate independent thread, because EndResult has to wait on Summation finishing.
You'd be surprised how much of this occurs, when you try to design what is known as "fine-grained multithreading" on various tasks of this nature.
Not everything lends itself to 'fine-grained multithreading', & this is just a single example.
What CAN lend itself to multithreading, more easily, is doing "coarse multithreading", where you separate discrete tasks (that do not share data, or have to wait out the result of 1 calculation per E.G. #1 above) onto DIFFERENT THREADS!
Using a game as an example?
E.G. #2 of 'coarse-multithreading':
Place game animation into the main/parent thread, sound processing onto another thread, networking code onto another thread, possibly AntiAliasing & AntiIsotropics onto yet another thread (if you have the game process it, as is often an option in them, vs. the vidcard & its drivers), etc. et al.
This latter example is by far, easier/simpler to do AND understand how to implement.
This is as far as using multiple thread design (what I call implicit multicpu/multicore usage), vs. EXPLICITLY multicpu/multicore coding (where YOU design the processor(s) #'s detections (and usage saturations), & then also manually schedule your threads across the least used CPU - because, today's OS kernel/core "process scheduler" components do this for you, & QUITE well!).
"Right now having a dual or quad core for most apps is like having a care with an extra engine or two in the trunk not connected to any drivelines." - by Bullfish (858648) on Thursday May 31, @09:41AM (#19336277)
With single-threaded apps (which actually have LESS overheads on a single core rig than multithreaded apps do), this is correct for the MOST part, but if you think about it? Even THEY can gain on a multicore/true smp multiCPU rig!
Consider this, on a 2 cpu/2 core rig:
Most of your apps today, if you look @ taskmgr.exe (w/ the processes tab in focus, & the threads column in view) ARE multithreaded (e.g.-> Here currently, of 38 processes running? I have 31 that run between 2-99 threads).
So, if processor/core #1 is @ or near 100% cpu usage due to say, some heavy single threaded task?
Good, let it have it & get its work done by hogging that CPU to itself!
Why?
Well, since the OS process scheduler will send the threads from other processes off to CPU/core #2,