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."
Thread beginning with comment 480268
To view parent comment, click here.
To read all comments associated with this story, please click here.
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 Parent 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 Parent 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 Parent Score: 1