backtop


Print 43 comment(s) - last by gfxBill.. on Sep 30 at 8:58 PM


Microsoft's Barrelfish operating system is an experimental OS looking to bring improved multicore performance to Microsoft's OS's  (Source: Network World)

"Barrelfish hackers and hangers-on, Zurich, August 2009 "  (Source: Microsoft/ETH Zurich)
Microsoft tests out multi-core improvements that will eventually be rolled into Windows

Microsoft has long cooked up new and experimental operating systems whose features eventually got rolled into its central Windows offerings.  Most recently it's been dabbling with Singularity, an experimental OS designed for increased reliability thanks to kernel, device drivers, and applications being written in managed SING# (an extension of C#) code.  Another test OS is Midori (not to be confused with the web browser), an OS that sandboxes applications for security and is designed for running concurrent applications, a feature geared towards cloud computing schemes.

Other recent efforts include its Windows Azure OS, a cloud computing OS currently offered for free to developers.

Now Microsoft has unveiled another new OS prototype codenamed "Barrelfish".  Barrelfish is an OS optimized to run on multi-core machines.  Namely, Barrelfish uses message passing and a database like system to pass information between cores.  Typically OS's use share memory schemes, which become very inefficient when resource demands are high.

The new OS was jointly created by ETH Zurich, a technology university, and Microsoft Research, located in Cambridge, Mass. 

Interestingly, it uses some open source BSD third-part libraries, which are "covered by various BSD-like open source licenses."  This has led to speculation that the new OS may be free and open source, not terms you typically would associate with Microsoft.

According to developers who have attended conferences on the new OS, it reportedly brings some of the Midori/Singularity sandboxing protections onboard.  Additionally, applications reportedly have an alternate route of accessing information from devices like graphics or sound cards.  A large deal of device information is reportedly stored in a central database that can be queried.

Writes developer "AudriUSA", "... instead of fully isolating program from device via driver, Barrelfish has a kind of database where lots of low level information about the hardware can be found. The kernel is single threaded and non preemptive. Scheduling is coupled with the message passing, an arrival of the message simply activates the waiting thread. It also uses a little bit of the microkernel concepts, running drivers in protected space, like L4 and in general pushing a lot into application domains."

As Intel and AMD expand their 4, 6, and 8-core lineups and approach even higher core counts, using these resources efficiently will be a crucial operating system responsibility.  It will be exciting to see what kind of improvements that Microsoft can accomplish with Barrelfish, as these improvements will surely be rolled into successors to Windows 7.



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: OS vs Applications?
By namechamps on 9/28/2009 10:28:13 AM , Rating: 5
A single threaded application can never by itself benefit from multiple cores.

However even if you run nothing but single threaded apps you likely are running 2 or more of them right?

That is where an OS optimized for multi-core can shine.

So in a situation where you are running a single application say a game and have no other apps runnings, and no other user services in the background this wouldn't do much.

However a situation where you have multiple apps running at the same time can be improved. Even windows 7 is rather weak when it comes to efficiently using 2+ processors and 3+ threads.


RE: OS vs Applications?
By MrPoletski on 9/28/2009 11:05:09 AM , Rating: 3
Any windows process can be assigned to a particular core and there many running regardelss of what you are doing. Most don't use much processor time at all, but some do.

You could have a single threaded game, but it makes calls to graphics drivers, sound drivers, perhaps a physics runtime and a disk Io handler. All those things can be run on a different core to the main game. However, this might not translate into a tangiable gain from adding extra cores because much of the work in that game is still done within the game engine because pipelining operations between all these subsystems the coder is writing for had not been thought of when coding that game.

To make what I just said make sense... a 'multicore ready' app is no good if each individual thread has to wait for the previous one to finish before it can start. yeah it'll use many cores, but it wont use them concurrently


RE: OS vs Applications?
By omnicronx on 9/28/2009 11:45:33 AM , Rating: 2
quote:
To make what I just said make sense... a 'multicore ready' app is no good if each individual thread has to wait for the previous one to finish before it can start. yeah it'll use many cores, but it wont use them concurrently
Asynchronous programming and multi threaded apps kind of go hand and hand these days. Anyone coding in the way you mention is not a good programmer. (IMO its not even a multicore 'ready' app in the first place, as opening another thread to have the first thread do nothing makes absolutely no sense).


RE: OS vs Applications?
By Murst on 9/29/2009 11:14:04 AM , Rating: 2
quote:
as opening another thread to have the first thread do nothing makes absolutely no sense

In even a pretty simple multi-threaded app, you generally need to create separate threads for security and thread safety. In many of these instances, it is very common and necessary to have the calling thread wait until the child thread has completed.


RE: OS vs Applications?
By erple2 on 9/29/2009 2:45:23 PM , Rating: 2
quote:
You could have a single threaded game, but it makes calls to graphics drivers, sound drivers, perhaps a physics runtime and a disk Io handler.


A multithreaded application will send those requests off to the graphics driver, sound driver, physics "driver", and IO handler and continue to do the next thing while a thread handles those. A non-multithreaded application won't do that. It'll continue to stagnate until the graphics driver returns status, the sound driver returns status, the physics runtime returns status/data, and the IO system returns status/data.


"My sex life is pretty good" -- Steve Jobs' random musings during the 2010 D8 conference














botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki