Submitted by “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.”
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.
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.
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.
Except that in BeOS days, Windows (and Linux) felt also unresponsive compared to BeOS and Windows and Linux haven’t improved much in responsiveness..
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.
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
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.
Except one doesn’t actually need that many since they spend 90% of their time idle. As stated, it is simple fact that BeOS is done the way it is because of those kernel limitations, the app_server engineers didn’t want to have to design it that way because it caused various other problems, such as the fact that one couldn’t have more than 192 windows at most, fewer than that if off-screen bitmaps are in use. A design using one or two threads watching the ports + a thread pool to handle the actual worker operations would have scaled significantly better (and been just as responsive), but that wasn’t possible owing to the aforementioned kernel limitations.
Except nothing about that design implicitly leads to more responsiveness for the user, that’s more a matter of how you handle locking for the various GUI/input operations. And nothing stops one from spawning off threads to perform things like blocking I/O operations, that’s basic software design. A BeOS window will block just as badly as a Windows one if you try and do I/O from the window looper thread (and quite a few apps on bebits do exactly that), seeing as the app_server threads won’t do much of anything without the window sending them drawing commands.
Except you haven’t, every single comment you’ve ever posted in this vein is the epitomy of the stereotypical clueless BeOS fanboy, as is your response here.
I don’t think these facts prove your point that BeOS is the same or less responsive to user interaction than Windows. The rationale for why it was designed so doesn’t disprove my assertion that having more threads in an app makes it more responsive under system load. I don’t think having a limitation of 192 windows seems like much of a problem. It think hitting this limit under normal use in the year 2000 seems unlikely. You point out interesting kernel limitations in BeOS, certainly you have done some homework. But this doesn’t give credibility to your point that BeOS is not more responsive than Windows.
I agree that this is software design, but I disagree that you find this design frequently in Windows apps. Although one can spawn off threads in Windows apps I do not think it commonly done. The example I gave on another forum is streaming a Netflix movie on Windows using the Chrome browser. Lots of apps lock up including Chrome, and Chrome is supposed to be multi-process. If you read through the BeOS development materials they constantly tell you when to multi-thread your applications and IO. It is highly encouraged and not generally difficult to do.
There are many poorly written apps on BeBits and Haikuware. On a well-written app it is less likely to happen. If an app developer spent any time testing an app that blocked on IO, causing the entire app to block, it would be easy to fix this.
BTW, thanks for sharing your points. From this exchange I am actually learning a bit of BeOS kernel history.
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.
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.
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.
Right. Unix has traditionally favored forking over threading, and modern unices are still heavily biased towards forking.
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.
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.
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.
The new thing in Barrelfish is the ability to have an OS with multiple kernels with NUMA architectures in multicore environments.
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,
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
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.
Unfortunately that statement was retracted.
No, it never was a statement by Microsoft. Just one guy’s bad practical joke, and one joke of a journalist who “confirmed it”.
agree,
Ill never forget what they did/do to VP8!! I love them for that.
die mpeg-la!
> 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.
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.
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.
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.
Who wants to write the comparison article?
We still have several other plans to go through before we get to Plan9…
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.
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.
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
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.
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.
Is it patent encumbered?
It come from an R&D project, of course it is. It’s why it’s not Apache licensed.