Slashdot Mirror
Multicore Requires OS Rework, Windows Expert Says
alphadogg writes "With chip makers continuing to increase the number of cores they include on each new generation of their processors, perhaps it's time to rethink the basic architecture of today's operating systems, suggested Dave Probert, a kernel architect within the Windows core operating systems division at Microsoft. The current approach to harnessing the power of multicore processors is complicated and not entirely successful, he argued. The key may not be in throwing more energy into refining techniques such as parallel programming, but rather rethinking the basic abstractions that make up the operating systems model. Today's computers don't get enough performance out of their multicore chips, Probert said. 'Why should you ever, with all this parallel hardware, ever be waiting for your computer?' he asked. Probert made his presentation at the University of Illinois at Urbana-Champaign's Universal Parallel Computing Research Center."
Oh please, this has been coming for years now. Why has it taken so long for the OS designers to get with the program? We've had multi-CPU servers for literally decades.
'Why should you ever, with all this parallel hardware, ever be waiting for your computer?'
Because I/O is always going to be slow.
Sent from my PDP-11
The problem is that most (if not all) peripheral hardware is not parallel in many senses. Hardware in today's computers is serial: You access one device, then another, then another. There are some cases (such as a few good emulators) which use muti-threaded emulation (sound in one thread, graphics in another) but fundamentally the biggest performance kill is the final IRQs that get called to process data. The structure of modern day computers must change to take advantage of multicore systems.
Isn't this the reason for Apple to have rolled out GrandCentral in Snow Leopard? If so, it seems it's not THAT hard to do - at least not that hard for a non-Windows OS.
Why should you ever, with all this parallel hardware, ever be waiting for your computer?' he asked.
Because it might be waiting for I/O.
That's no reason for the entire GUI to freeze on Windows when you insert a CD.
You wait because some programmer thought it was more important to have animated menus than a fast algorithm. You wait because someone was told "computers have lots of disk space." You wait because the engineers never tested their database on a large enough scale. You wait because programmers today are taught to write everything themselves, and to simply expect new hardware to make their mistakes irrelevant.
You do not have a moral or legal right to do absolutely anything you want.
I noticed the same on my mac. With a set of eight CPU graph meters in the menu bar, they're almost always evenly pitched anywhere from idle to 100%, with a few notable exceptions like second life, some photoshop filters, and firefox of all things.
When booted into Win, more often than not I have two cores pegged high, and the others idle. Getting even use out of all cores is the exception, not the rule.
And if you knew what it did, you'd know it isn't going to help.
It's called Grand Central Dispatch.
Despite having a name and a Wikipedia page. it's not doing a good enough job.
Windows explorer sucks. It always just abandons copies after a fail - even if you're moving thousands of files over a network. Yes, you're left wondering which files did/didn't make it. It's actually easier to sometimes copy all the files you want to shift locally, then move the copy, so that you can resume after a fail. It's laughable you have to do this, however.
But it's not a concurrency issue, and neither, really, are the first 2 problems you mention. They're also down to Windows Explorer sucking.
The largest single system image I'm aware of runs Linux on a 4096 processor SGI machine with 17TB RAM. Maybe He means that Windows needs rework?
Can You Say Linux? I Knew That You Could.
Are you running a 9 year old version of OSX too, or are you comparing a two generation old Windows version to a nice new Mac version? It really sounds like you are comparing apples (snicker) to oranges. After all, both Vista and Windows 7 have no problem running for a long, long time between reboots and don't get slow during that time.
I'm not sure I get it - GCD just looks like a threadpool library. Windows has had a built-in threadpool API that's been available since Windows 2000, and it seems to do pretty much the same thing as GCD.
Wow, another Mac fanboy compairing his nice shiny new Mac to an outdated and replaced (2 times over) operating system. I bet he will say his Ipad will out perform a netbook too. Though the netbook can multitask, run virtually any windows app, has wifi, you can connect an external dvd and (gasp) it can be a color Ebook reader just like the ipad!!
I wish I could mod you higher than +5, you just summed up some of the things that bother me most about the OS that is somehow still the most popular desktop OS in the world.
.
To anyone using Windows (XP, Vista or 7) right now, go ahead and open up an Explorer window, and type in ftp:// followed by any url.
Even when it's a name that obviously won't resolve, or an ip of your very own local network of a machine that just doesn't exist, this'll hang your Explorer window for a couple of solid seconds. If you're a truly patient person, try doing that with a name that does resolve, like ftp://microsoft.com . Better yet, try stopping it.... say goodbye to your explorer.exe
This is one of the worst user experiences possible, all for a mundane task like using ftp. And this has been present in Windows for what, a decade?
+1 Funny Signature
or basically replaces windows with something else.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
The trick with GCD is that it is somewhat more high-level than a simple thread pool - it operates in terms of tasks, not threads. The difference is that tasks have explicit dependencies on other tasks - this lets scheduler be smarter about allocating cores.
The author is talking about a complete OS redesign, not a new threading system.
That is simply not true. In fact, that is what Grand Central Dispatch (Snow Leopard, OS X 10.6) is all about. The OS handles the threads, not the programmer.
Not only does it work, it is the wave of the future. Eventually, all machines and OSes will work that way because no programmer wants to jump through outrageous hoops to deal with 128 cores. Or even 4.
I love how Microsoft can come along in 2010 and with a straight face say it's about time they took multiprocessing seriously. Or say it's about time we started putting HTML5 features into our browser. And we're finally going to support the ISO audio video standard from 2002. And by the way, it's about time we let you know that our answer to the 2007 iPhone will be shipping in 2011. And look how great it is that we just got 10% of our platform modernized off the 2001 XP version! And our office suite is just about ready to discover that the World Wide Web exists. It's like they are in a time warp.
I know they have product managers instead of product designers, and so have to crib design from the rest of the industry, necessitating them to be years behind, but on engineering stuff like multiprocessing, you expect them to at least have read the memo from Intel in 2005 about single cores not scaling and how the future was going to be 128 core chips before you know it.
I guess when you recognize that Windows Vista was really Windows 2003 and Windows 7 is really Windows 2005 then it makes some sense. It really is time for them to start taking multiprocessing seriously.
I am so glad I stopped using their products in 1999.
so basically a big pile of C64 wired to a single keyboard and screen, via a BIG kvm switch?
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
You may not have to write your code around threading, but you then have to write it around grand central dispatch. Having GCD available is going to do absolutely nothing for a program that was not written with GCD in mind. Its changing one set of problems/features for another. Writing multi-threaded software isn't exceptionally hard. I have done a lot of it. It may take a lot less code with GCD, but you also give up control. Even using GCD with code blocks you still have to deal with the problems that can be a pain in the ass, things like concurrency, blocking and munging data.
Windows Explorer no longer kills network transfers after a failure as of Windows Vista.
Maybe some of the people complaining about Windows should stop using a version thats 9 years old (XP). Red Hat 7.2 isn't particularly great by today's standards either.
There is no information in the article. He asks if we have multi-core CPUs why would we ever be waiting for something to happen on our PC? Well, cuz the slowest thing in the PC is the hard drive... and more people only have one. Prioritized IOs don't make that much of a difference because even if my disk was idle, and the low priority IO (Vista has these BTW, 2 IO priorities) moves the disk head, and then my higher priority IO comes in, it's been delayed because it has to move back.
Disk IO is the biggest bottleneck and redesigning Linux or Windows isn't going to solve that problem. L1,2,3..X cache -> memory -> disk, as long as we have that heirarchy and there is such a disparity between the layers, no OS rewrite will help.
That's why massively parallel systems are so radically different from general purpose computers and ususally only useful on specific tasks (e.g. SIMD implementations etc.)
Research in highly parallel IO is addressing the issue, but won't help home/small business.
No wonder this dude's peers at MS disagree w/him.
You will have to design your apps and supporting hardware to take advantage of whatever parallelism you have available, and break up your workload intelligently.
Yeah you'll have to pay people who understand how to do concurrent programming properly.
App programmers do not deserve all the blame. The tools for multithreaded development are primitive and difficult to use correctly. It is difficult and expensive to make good reliable MT software.
Many years ago if I wanted a list of data I would manually malloc, memset and free data. There were lots of bugs because of the tedious management of memory. Now in C++ I write vector, or in Python I use a_list = [] and POOF! I don't need to keep track of ANY details.
The state of multithreading libraries and tools must evolve to the point where normal (ie not VERY skilled or creative) developers can handle them without much thinking. This may require a paradigm shift similar to the object-oriented one in the eighties.
Objects and exceptions and stack unwinding seem almost obvious to us, but some people had to pave the way for their use. We need some skilled computer scientists to work with skilled library developers to make a new paradigm for developing MT apps. When these ase of yet undiscoverd (or unpopularized) paradigms have been developed, we better hope that big players have the incentive and capacity to implement them in their current systems.
I for one welcome our multithreaded overlords... when they get here.
What's wrong with at least some operating systems doesn't even have anything to do with multiple cores per se. They're simply designing the OS and its UI incorrectly, assigning the wrong priorities to events. No event should EVER supersede the ability of a user to interact and intercede with the operating system (and applications). Nothing should EVER happen to prevent a user being able to move the mouse, access the start menu, etc., yet this still happens in both Windows and Linux distributions. That's a fucked-up set of priorities, when the user sitting in front of the damned box - who probably paid for it - gets second billing when it comes to CPU cycles.
It doesn't matter if there's one CPU core or a hundred. It's the fundamental design priorities that are screwed up. Hell should freeze over before a user is denied the ability to interact, intercede, or override, regardless how many cores are present. Apparently hell has already frozen over and I just didn't get the memo?
Why should you ever, with all this parallel hardware, ever be waiting for your computer?'
For a lot of problems, for the same reason that some guy who just married 8 brides will still have to wait for his baby.
Of course, he'll be able to get 8 babies at once, assuming none of the processes crash during the computation.
That improves bandwidth, but not latency: almost 1 baby/month, but 9 months of latency.
The guy could try interleaving the pregnancies, in order to get the illusion of lower latency.