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."
A big problem is the event-driven model of most user interfaces. Almost anything that needs to be done is placed on a serial event queue, which is then processed one event at a time. This prevents race conditions within the GUI, but at a high cost. Both the Mac and Windows started that way, and to a considerable extent, they still work that way. So any event which takes more time than expected stalls the whole event queue. There are attempts to fix this by having "background" processing for events known to be slow, but you have to know which ones are going to be slow in advance. Intermittently slow operations, like an DNS lookup or something which infrequently requires disk I/O, tend to be bottlenecks.
Most languages still handle concurrency very badly. C and C++ are clueless about concurrency. Java and C# know a little about it. Erlang and Go take it more seriously, but are intended for server-side processing. So GUI programmers don't get much help from the language.
In particular, in C and C++, there's locking, but there's no way within the language to even talk about which locks protect which data. Thus, concurrency can't be analyzed automatically. This has become a huge mess in C/C++, as more attributes ("mutable", "volatile", per-thread storage, etc.) have been bolted on to give some hints to the compiler. There's still race condition trouble between compilers and CPUs with long look-ahead and programs with heavy concurrency.
We need better hard-compiled languages that don't punt on concurrency issues. C++ could potentially have been fixed, but the C++ committee is in denial about the problem; they're still in template la-la land, adding features few need and fewer will use correctly, rather than trying to do something about reliability issues. C# is only slightly better; Microsoft Research did some work on "Polyphonic C#", but nobody seems to use that. Yes, there are lots of obscure academic languages that address concurrency. Few are used in the real world.
Game programmers have more of a clue in this area. They're used to designing software that has to keep the GUI not only updated but visually consistent, even if there are delays in getting data from some external source. Game developers think a lot about systems which look consistent at all times, and come gracefully into synchronization with outside data sources as the data catches up. Modern MMORPGs do far better at handling lag than browsers do. Game developers, though, assume they own most of the available compute resources; they're not trying to minimize CPU consumption so that other work can run. (Nor do they worry too much about not running down the battery, the other big constraint today.)
Incidentally, modern tools for hardware design know far more about timing and concurrency than anything in the programming world. It's quite possible to deal with concurrency effectively. But you pay $100,000 per year per seat for the software tools used in modern CPU design.
Well - I can tell you that Dave Probert saw his first multi-processor about 28 years ago at Burroughs corporation. It was a dual-processor B1855. I had the pleasure with working with the guy way back then. From what I recall he then went on to work at FPS systems which was an array processor that you could add onto other machines (I think vaxen...but I could be wrong there..)
Anyway - he has been around ALONG time.
Have you compiled your kernel today??
Apple's grand-central dispatch (GCD) solution is really primitive. It's just a simple thread-pool, where the programmer breaks their program down into tasks that can be executed independently then queues them for execution by the thread-pool.
GCD is not in the slightest innovative, except for a hack that allows "c" programmers to write tasks with slightly more convenience, by adding limited "closure" support to the language.
Similar concepts can be found all over the place; just see the "see also" section on the wikipedia article:
http://en.wikipedia.org/wiki/Grand_Central_Dispatch
Using any of the libs listed in that "see also" section, you can get GCD equivalent behaviour on unix/windows, and have been able to for years.
There are also languages with far superior parallel-processing abilities, where the effort is done by the compiler/environment, not the programmer. See any functional language, eg Haskell or Erlang. Write a program in these languages, and the parallel-processing happens just about automatically.
Adding parallelism to the *OS* is quite a different issue, and not one that Apple's GCD addresses.
Citation needed? I think you'll find that Iphone only appears to outperform Android because Android is doing a lot more then the Iphone. Further more many things that work on Android do not work on Iphone, slashdot for instance works fine on my HTC Dream or newer Motorola Milestone with the standard browser, it works even better with Dolphin browser.
This cannot be a fair comparison until the Iphone can do everything that Android phones can, unless you want to compare functionality where Iphone is an epic failure.
Now I can tell you're full of it. All prices are incl of local taxes, and UK VAT does not apply outside the EU for those in Australia, Canada and the US.
UK Expansys
Motorola Milestone GBP 379
Nexus 1 GBP 599
Iphone 32 GB GBP 799
AU Mobicity
Motorola Milestone A$659
Nexus 1 A$849
Iphone 16 GB A$959
The cheapest Iphone 3GS available is A$100 more expensive then the newer Motorola Milestone (droid for the Yanks) and Google Nexus One. Not to mention that both the Milestone and Nexus One can do more as well as lack the restrictions of the Iphone. But then again I suspect you were merely looking to confirm your quite obvious bias rather then do an accurate comparison.
Apple's operating systems are not very well optimised, not even as much as Windows operating systems, Apple's OS pretend to have optimisation by providing the OS with more hardware then it needs and limiting functionality to prevent any perceived loss of speed. Most people using a Mac or Iphone rarely use the full power of the hardware, ergo an un-optimised OS goes unnoticed by the user. Here is the core of the design (in an engineering perspective) a design does not have to work well, it just has to work. The vast majority of people will ignore tiny flaws if they can get the task done, OTOH if a computer doesn't do the task the user will get annoyed no matter how pretty the interface.
As a good developer friend of mine likes to say, "If given the choice, a user will press the 'I just want it to work today' button". OSX provides this very shiny button but only in a few select places, Windows provides this not so shiny button almost everywhere. This is why Windows is still the number one OS on the planet.
Calling someone a "hater" only means you can not rationally rebut their argument.