Linked by Thom Holwerda on Sun 10th Jul 2011 18:50 UTC, submitted by moondevil
Microsoft "The Microsoft and ETH Zurich research teams have published the source code of Barrelfish, a multikernel operating system for the multicore heterogeneous hardware of the future. Today's operating systems have been adapted to work on multiprocessor and multicore hardware, but they were not initially designed with multicore in mind, and they are not ready for heterogeneous hardware with hundreds of cores that is to come in the following ten years. The main problem is the concept of shared-memory and the contention arising from accessing the same data protected by locks. This is the problem that Barrelfish wants to address."
Order by: Score:
przemo_li
Member since:
2010-06-01

There are research projects to use gpu for Linux kernel computations, and Linux is capable of using thausands processors, so I can not see why Barrelfish is any new. Any way, good luck to this effort and similar.

Reply Score: 1

Elv13 Member since:
2006-06-12

Windows run on thousand of core too, it's not the point of this project. The only OS with real multicore support was BeOS. Everything else is patched to support it instead of designed to support it.

Reply Score: 2

moondevil Member since:
2005-07-08

The Windows NT family was a multicore operating system since the first release as well.

Reply Score: 4

renox Member since:
2005-07-06

The Windows NT family was a multicore operating system since the first release as well.


Except that WindowsNT also had to support a lot of old applications and APIs which were not designed for multicore in mind, so in practice Windows and Linux still feel much slower than BeOS did.

Reply Score: 3

joshv Member since:
2006-03-18

"The Windows NT family was a multicore operating system since the first release as well.


Except that WindowsNT also had to support a lot of old applications and APIs which were not designed for multicore in mind, so in practice Windows and Linux still feel much slower than BeOS did.
"


*Sigh* The reasons Windows feels slower than BeOS is because applications these days do much much more than they did in the days on BeOS. They use more memory, they load larger files, they run more demanding algorithms - all because they can. Sure BeOS could run 10 postage stamp sized videos at once - so what - my computer today is expected to decompress full HD h.264 will Adobe Lightroom sucks about 2GB of RAM in the background.

Reply Score: 1

renox Member since:
2005-07-06

*Sigh* The reasons Windows feels slower than BeOS is because applications these days do much much more than they did in the days on BeOS.


Except that in BeOS days, Windows (and Linux) felt also unresponsive compared to BeOS and Windows and Linux haven't improved much in responsiveness..

Reply Score: 2

AndrewZ Member since:
2005-11-15

Palm in face. No, Windows and Linux applications 'feel' slower because the operating systems were designed for 'throughput' instead of 'response'. These are operating system parameters that you would learn in undergraduate OS class.

BeOS/Haiku was designed from the very beginning for excellent responsiveness. It has many extra threads in the application objects specifically for this purpose. OSNews will run an in-depth article on this shortly.

Reply Score: 2

anevilyak Member since:
2005-09-14


BeOS/Haiku was designed from the very beginning for excellent responsiveness. It has many extra threads in the application objects specifically for this purpose. OSNews will run an in-depth article on this shortly.


Please, please, please stop spreading this nonsense already. This was already mentioned on other sites where you keep blabbing Be's marketing kool-aid, the only reason it had massive number of threads was kernel limitations that meant there was no way to watch multiple ports for messages with a single call, ergo one had to spawn a thread for every single port one wanted to watch. Given that each window is a BLooper (which entails port + message queue), that results in each window having to have a thread for that reason, and that reason alone. It has absolutely nothing to do with what makes BeOS responsive. Furthermore, Be's scheduler really isn't something you want to be singing praise for in the context of scalability, it's quite horrible at that, especially since, among other things it completely lacked any support for affinity. For the same reason, comparing it to something like Barrelfish would be laughable.

Edited 2011-07-11 14:02 UTC

Reply Score: 3

AndrewZ Member since:
2005-11-15

I am afraid that we have a difference of opinion on this matter. Here are the facts, not marketing cool-aid: Each BeOS/Haiku GUI application has in fact 4 threads. One in the application BLooper, one in the Window BLooper, and two in the servers to process the BLoopers. And you can easily add more threads if you want them. This is a design that leads to greater responsiveness. This is a simple matter of OS design principles that you learn in university.

A standard Windows application has one single thread. This thread is often blocked by IO operations such as access to a CD, a network operation, a slow disk, or dialog operations. By this design, a basic Windows application is also single core. This is a design that leads to less responsiveness to the user.

I have done more than just repeat what others have said. I am in the process of writing apps where performance can be measured. I really have no interest in banging the drum for dead companies where there was no innovation. I really am interested in the innovation and what makes Haiku different.

Reply Score: 1

Flatland_Spider Member since:
2006-09-01

BeOS was designed for maximum responsiveness under any condition, so the applications have nothing do with this. BeOS was aggressively multithreaded, so it could respond whenever the user had input. The scheduler was better, and the OS was just a better design.

WinNT and Linux aren't designed to be responsive to user input. For all their advances, they are still carry the legacy of the single threaded, uniprocessor paradigm.

Also, the 10 video test was a pretty heavy test back in the day. I remember my friend and I trying to get BeOS to buckle, but we could never do it. We were running BeOS on a AMD K6 with, maybe, 64MB of RAM, so the hardware was dated even back then.

Reply Score: 1

moondevil Member since:
2005-07-08

The Windows kernel is heavily multi-threaded, how come it is not multicore aware?.

Granted, NT 3.5, 5.51 and 4.0 had a few issues migrating processes between cores under heavy load. Something that was fixed on the Windows 2000, when the scheduler went through a rewrite.

Actually regarding multi-threading, Windows did offer a better design than UNIX. Because UNIX only offer proper multi-threading support later on.

As for BeOS. It was a nice OS, but now it is dead. Time to move on.

Reply Score: 2

Flatland_Spider Member since:
2006-09-01

The Windows kernel is heavily multi-threaded, how come it is not multicore aware?.


Because it's not designed that way. Threading is a feature of the OS, and by the time it's added the problem of mixing two completely different types of machine code has been solved.

I'm having a hard time coming up with a way to do that without replicating hardware. Obviously, this is a problem for people much smarter then I am.

Actually regarding multi-threading, Windows did offer a better design than UNIX. Because UNIX only offer proper multi-threading support later on.


Right. Unix has traditionally favored forking over threading, and modern unices are still heavily biased towards forking.

As for BeOS. It was a nice OS, but now it is dead. Time to move on.

I have. I run Linux on my personal stuff.

It's important to not forget about it. We can still learn a lot from BeOS.

Reply Score: 1

Bill Shooter of Bul Member since:
2006-07-14

That's a meaningless point. The implication there is that a first design is better than a gradual re-factoring of an existing system. I strongly disagree. I believe the hallmark of a good system is its ability to be continuously improved through a series of gradual changes to meet goals completely outside of its original design. I believe in evolution, not divine creation of software.

Furthermore, the design of BeOS has not actually been tested at the level of Linux. There aren't systems with thousands of CPU's with large uptimes running BeOS now, and there never have been.

Reply Score: 4

Phucked Member since:
2008-09-24

Windows run on thousand of core too, it's not the point of this project. The only OS with real multicore support was BeOS. Everything else is patched to support it instead of designed to support it.



You mean multiprocessor support because multicore was not around in the days of BeOS. Also BeOS does not have better Multi(core) SMP support than any old school HPC UNIX, Linux or a few of the BSDs of the last 10 years.

BeOS was a awesome OS in its day but it is not good in all areas, its was a better OS than Windows 98 but compared to FreeBSD, Linux or Windows 2000 it has alot of short comings.

Reply Score: 1

moondevil Member since:
2005-07-08

The new thing in Barrelfish is the ability to have an OS with multiple kernels with NUMA architectures in multicore environments.

Reply Score: 2

Code was avaliable anyway
by witold.bolt on Sun 10th Jul 2011 20:38 UTC
witold.bolt
Member since:
2009-04-17

Hi.

The code was also avaliable earlier - nothing new happened. The only good thing is that there is a public repository avaliable, and releasese should be more frequent.

Btw - yes, this project is sponsored by Microsoft Research, and it builds correctly only under Linux and it uses Mercurial for source code management, and Haskell for some tools. Cool stuff ;)

Br,

Reply Score: 2

RE: Code was avaliable anyway
by JAlexoid on Mon 11th Jul 2011 09:34 UTC in reply to "Code was avaliable anyway"
JAlexoid Member since:
2009-05-19

I believe that MS research is the branch of MS that can say FFFFFFFFFUUUUUUUUUUUUUU!!!!!!!!! to everyone else. They are the guys that baffle MS zealots at TechEd's

Reply Score: 3

ms foss trysts
by fran on Sun 10th Jul 2011 21:32 UTC
fran
Member since:
2010-08-06

MIT license...Am i cynical or is this mostly the last stage of MS losing interest.
Dont get me wrong. Not that the project is bad or something ..mostly a change in direction or focus.
Like when they put the ironpython and ironruby on apache license.

Great for open source though.Anyway...well take it..thanks

I keep tabs on big companies supporting open source.
Google wins this year...like most other years.
Mainly through Google summer of code sponsorships.

http://www.google-melange.com/gsoc/projects/list/google/gsoc2011

MS has open sourced Visual basic 6 recently and now this OS. They have a few employees assisting in other foss project on payroll.
It has an employee working on the free paint.net ..though this is not open source anymore.
It has a developer that assist the mono team. It also assist Drupal though not sure in which way.
It host Codeplex also.

http://www.microsoft.com/opensource/directory.aspx
http://www.codeplex.com/

Secretly I think MS like opensource in there personal capacity. The principles of it. But it's the two hats scenario.

Reply Score: 5

RE: ms foss trysts
by mappy on Sun 10th Jul 2011 22:26 UTC in reply to "ms foss trysts"
mappy Member since:
2010-06-02

MS has open sourced Visual basic 6 recently

Unfortunately that statement was retracted.

Reply Score: 1

RE[2]: ms foss trysts
by Bill Shooter of Bul on Mon 11th Jul 2011 20:03 UTC in reply to "RE: ms foss trysts"
Bill Shooter of Bul Member since:
2006-07-14

No, it never was a statement by Microsoft. Just one guy's bad practical joke, and one joke of a journalist who "confirmed it".

Reply Score: 2

RE: ms foss trysts
by andih on Sun 10th Jul 2011 22:33 UTC in reply to "ms foss trysts"
andih Member since:
2010-03-27

agree,
Ill never forget what they did/do to VP8!! I love them for that. ;)

die mpeg-la!

Reply Score: 2

RE: ms foss trysts
by renox on Mon 11th Jul 2011 08:38 UTC in reply to "ms foss trysts"
renox Member since:
2005-07-06

> MIT license...Am i cynical or is this mostly the last stage of MS losing interest.

Maybe, but anyway if they want to regain control of the derivative based on their code, they could use patents.

Remember that Microsoft now earn a lots of money thanks to patent, so I wouldn't use any code Microsoft provide (even with MIT or BSD license) unless they also give a strong proof that they won't use any patent that they have on the software.

Reply Score: 3

RE[2]: ms foss trysts
by vodoomoth on Mon 11th Jul 2011 10:37 UTC in reply to "RE: ms foss trysts"
vodoomoth Member since:
2010-03-30


Remember that Microsoft now earn a lots of money thanks to patent, so I wouldn't use any code Microsoft provide (even with MIT or BSD license) unless they also give a strong proof that they won't use any patent that they have on the software.

I think this is overly paranoid. You don't offer things for free and then turn around and start yelling and whining that people stole these same things from you: I'm sure "don't offer it in the first place" is what the courts will reply to MS if they ever start suing people. They might even get sued themselves for misleading people into jumping in that trap.

Reply Score: 2

RE[3]: ms foss trysts
by JAlexoid on Mon 11th Jul 2011 23:14 UTC in reply to "RE[2]: ms foss trysts"
JAlexoid Member since:
2009-05-19

It's the new incarnation of 3xE (Embrace, Extend, Extinguish). And East Texas court will gladly find in favor of the patent holder... since the BSD like licenses have no patent grants in them.

Reply Score: 2

RE: ms foss trysts
by allanregistos on Tue 12th Jul 2011 03:19 UTC in reply to "ms foss trysts"
allanregistos Member since:
2011-02-10



MS has open sourced Visual basic 6 recently and now this OS. They have a few employees assisting in other foss project on payroll.
o.


Common.. You've got your source wrong. Googling Visual Basic 6 open source gets you nowhere but:
http://www.infoq.com/news/2011/05/VB6-Rumors
It is a rumor.

Reply Score: 1

Barrelfish, BeOS, Plan9
by AndrewZ on Mon 11th Jul 2011 00:06 UTC
AndrewZ
Member since:
2005-11-15

Who wants to write the comparison article?

Reply Score: 3

RE: Barrelfish, BeOS, Plan9
by JAlexoid on Mon 11th Jul 2011 09:36 UTC in reply to "Barrelfish, BeOS, Plan9"
JAlexoid Member since:
2009-05-19

We still have several other plans to go through before we get to Plan9...

Reply Score: 5

Worthwhile?
by jonas.kirilla on Mon 11th Jul 2011 15:56 UTC in reply to "Barrelfish, BeOS, Plan9"
jonas.kirilla Member since:
2005-07-11

They are three rather different designs. BeOS comes off as the most conventional.

Plan9 was designed as a distributed system, meant to replace unix. BeOS was designed as a GUI workstation meant to replace MacOS classic. Barrelfish is a research OS focusing on new forms of multicore.

A discussion on these three systems would probably deteriorate into one on how microkernels are superior/epic fail, and people failing to realize that neither BeOS nor Plan9 are microkernels (BeOS not at all and Plan9 at least not in any strict sense), and falsely attributing performance, snappyness or some other random quality to this invalid assumption.

IMO it would be more interesting to compare e.g. Plan9/QNX-Neutrino/Genode-on-L4 or JNode/Jxos/Singularity.

Reply Score: 5

RE: Worthwhile?
by AndrewZ on Mon 11th Jul 2011 16:08 UTC in reply to "Worthwhile?"
AndrewZ Member since:
2005-11-15

Plan9 was designed as a distributed system, meant to replace unix. BeOS was designed as a GUI workstation meant to replace MacOS classic. Barrelfish is a research OS focusing on new forms of multicore.


I have to admit that I have not yet taken time to read about Barrelfish. I expect to do so. I have read a bit about Plan 9. To simply say that Plan 9 was written as a replacement for UNIX is a big understatement. The Plan 9 kernel could distribute its processing across networked computers dynamically. This is pretty amazing. Plan 9 itself is based on some astounding design principles. I would not be surprised if some of those principle are resurrected in a future OS.

Haiku has an interesting feature - you can use the Pulse demo to dynamically turn on and off CPU cores. I am not sure I have seen this on other OSs outside the BIOS. Maybe someone else can comment on this.

Reply Score: 2

RE[2]: Worthwhile?
by anevilyak on Mon 11th Jul 2011 16:18 UTC in reply to "RE: Worthwhile?"
anevilyak Member since:
2005-09-14


Haiku has an interesting feature - you can use the Pulse demo to dynamically turn on and off CPU cores. I am not sure I have seen this on other OSs outside the BIOS. Maybe someone else can comment on this.


That feature would be trivially doable on just about any OS, the way it works in BeOS/Haiku isn't by actually physically disabling the CPU, it simply tells the scheduler to not schedule anything other than the idle thread on it (until one marks that CPU as enabled again in Pulse or ProcessController) ; the CPU is still very much active.

Reply Score: 3

RE[3]: Worthwhile?
by AndrewZ on Mon 11th Jul 2011 16:43 UTC in reply to "RE[2]: Worthwhile?"
AndrewZ Member since:
2005-11-15

That feature would be trivially doable on just about any OS, the way it works in BeOS/Haiku isn't by actually physically disabling the CPU, it simply tells the scheduler to not schedule anything other than the idle thread on it (until one marks that CPU as enabled again in Pulse or ProcessController) ; the CPU is still very much active.


Thanks for correcting my misconception, interesting to know. If you were going to trivially code that in Windows, what would the code look like? Just curious.

Edited 2011-07-11 16:44 UTC

Reply Score: 2

RE[4]: Worthwhile?
by anevilyak on Mon 11th Jul 2011 17:27 UTC in reply to "RE[3]: Worthwhile?"
anevilyak Member since:
2005-09-14


Thanks for correcting my misconception, interesting to know. If you were going to trivially code that in Windows, what would the code look like? Just curious.


I meant in the context of the kernel it'd be trivial. The way it works on Haiku is that there's a per-CPU data structure in the kernel that describes the CPU and various scheduling-related information related to it. one of said pieces of information is a simple boolean indicating that the CPU is enabled or not. To go with that, there's a syscall that allows one to set said boolean (which is what Pulse or anyone else wanting to do that calls). When the thread scheduler on a given CPU kicks in, it looks at that first, and if that boolean is set, it simply goes straight to the idle thread pool to pick the next thread to schedule. Otherwise it does the usual scheduling run (which in Be/Haiku's case effectively amounts to: 1) round-robin select any real time threads that are ready. 2) If none, round robin through the non-realtime threads, except pull a random number when selecting one which decides whether or not to skip the thread on this run. This is done to allow lower priority threads a chance to occasionally run in the event that a higher pri one goes into a loop due to a bug or whatnot, since it allows some modicum of control to kill the offending process, as it means the GUI will occasionally get some cycles.)

On Windows one can do something loosely similar in Task Manager if you right click a process and pick "Set Affinity". This allows you to restrict the subset of CPUs a given process is allowed to run on. Not entirely the same thing, but what you're doing with Pulse is effectively the same as doing that for every single process in the system.

Reply Score: 2

RE[2]: Worthwhile?
by jonas.kirilla on Mon 11th Jul 2011 21:57 UTC in reply to "RE: Worthwhile?"
jonas.kirilla Member since:
2005-07-11

Plan9 was created by people that had been part in creating Unix. They were unsatisfied with how unix developed as it grew addititional features, e.g. networked filesystems, new forms of interprocess-communication, etc, and set out to design something better. So of course its not a simple clone or replica of unix. It was meant to replace unix - by being superior.

The keyword here is 'distributed', which implies the feature you mention. Plan9 was, unlike unix, designed with these things in mind and its creators indeed meant for it to replace Unix. Sadly that didn't happen.

Reply Score: 2

Comment by shmerl
by shmerl on Mon 11th Jul 2011 17:21 UTC
shmerl
Member since:
2010-06-08

Is it patent encumbered?

Reply Score: 2

RE: Comment by shmerl
by Elv13 on Tue 12th Jul 2011 02:00 UTC in reply to "Comment by shmerl"
Elv13 Member since:
2006-06-12

It come from an R&D project, of course it is. It's why it's not Apache licensed.

Reply Score: 2