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?"
They're going to aren't they? Windows Vista '09 Multicore Edition, only valid for up to 16 cores, Windows Vista '09 Multicore Extreme Edition, 16-24 cores...
And so it goes.
I can't wait - an OS designed through-and-through for multiple cores, and it's only six or more years away!
Now we all will have buy to 8core machines with 16G memory as a minimum model, based on what just happened with Vista.
How is that helping their customers? Oh yeah, DELL is their customer, not us.
There are three issues in multi-processor programming.
(1) OS and language support in the form of threading models
(2) OS and language support in the form of scheduling algorithms
(2) Application support in the form of using those threading models to develop program components that can run concurrently.
Let Microsoft focus on #1 and #2, and application developers focus on #3. The OS should not, IMHO, try to take a program that is not written to take advantage of multiple processors, and run it in a concurrent environment. That's just asking for trouble!
Advanced threading models that allow application developers better control over how their threads are executed, and scheduling algorithms that distribute threads across the multiple cores and processors, will pave the way for application developers to write applications that can truly benefit from a multi-core environment.
As an application developer, one of the biggest problems I've encountered in developing multi-threaded applications is the ability to easily control what can run concurrently, and what can't. I have almost no ability to tell the operating system which threads I want to run concurrently, and which I want it to time-share.
Let Microsoft, and language developers, focus on the first two tasks. Make the tools available to application developers, and let application developers take advantage of those tools.
Why bother talking about multi core supporting operating systems when we still haven't embraced 64-bit technology yet. Why bother pushing for a new technology when the current 'new' technology hasn't even been implemented yet. IMHO, Microsoft should have made Vista 64-bit only and kept XP alive for the 32-bit people who don't want to migrate. This would force people to write 64-bit drivers and software in order to be on 'average Joe's' new PC. Instead, they've done what they've been doing for the past 30 years, compromising due to lack of adaptation.
Now I'm no supporter of Microsoft. I personally hate them. But you have to see where I'm coming from.
I recently built a new PC for my parents. It was a simple box with a Sempron 3000, 1gb DDR, 80Gb HDD, etc. It was all 64-bit compatible so I though Vista Home Premium 64-bit would be the best way to go. Their scanner isn't supported, their antivirus isn't supported, and the devices and software they use that DO work on Vista, are all running in 32-bit mode because there is no equivalent for 64-bit.
Please lets implement the great technology we have before concentrating on the future.
You moved your mouse. Please restart Windows for changes to take effect.
"just using MS software only uses 1 core by default" Really depends on which software you're using. A lot of applications like Word, Excel, etc don't usually do process-intensive tasks and the act of spreading the work over multiple threads would actually decrease performance (there is overhead for each thread, context switches, etc). Those apps are more often IO-bound... either waiting for user IO or disk IO. However, if you're using software like SQL Server which performs tasks that do benefit from multiple concurrent threads, it does use multiple cores out of the box. (Yes, it's actually just using multiple threads out of the box, but Windows tosses those to multiple cores... trying not to be too pedantic here) Also if you're manually setting the affinity of processes, you're probably inadvertently decreasing your performance. Windows will spread processing across multiple cores by default (not only using 1 core like you say). When you specifically set the affinity, you're not really moving the process to a different core so much as saying "don't use this core even if it's not being used by anything else." Multi-threading with IO intensive applications should make use of IO completion ports in Windows. That will give you much better perf than trying to manually control which core you explicitly want a thread running on. Keep in mind that IO is orders of magnitude slower than processing, and more often than not that's now the bottleneck in systems. Check out http://www.microsoft.com/technet/sysinternals/info rmation/IoCompletionPorts.mspx/ for more info. Unfortunately, there are a lot of applications out there (both from MS and other vendors) that do multi-threading poorly. Hopefully if MS re-writes some of the Windows infrastructure to make multi-threading easier for applications we'll see better apps that more properly take advantage of the hardware that's out there.
Five years from now Windows will support multiple cores. Which is what OS X is doing on my MacBook Pro RIGHT NOW.
I believe the largest SMP system that OSX has ever been run on is 8 cores. Windows has run on a 64 CPU system and Linux on a 1024 CPU system.
So I'm kind of struggling to understand how OSX is superior in this regard. I know there must be a technical explanation, because it's not like Mac owners to post single lines of obvious bullshit in an attempt to advocate their systems while actually just annoying the fuck out of everyone.