Linked by Michael on Thu 21st Jul 2011 14:08 UTC
Thread beginning with comment 481879
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
One of the things I've always read is that microkernel OSes based on the likes of Minix and Hurd are going to be noticeably slower due to all the overhead of message passing between processes, etc.
I don't think that must be a given. QNX for instance uses a message-passing, small-privileged-kernel model, and it is known for its real-time performance -- even on 8086 CPUs.
That's probably not the same kind or performance as raw throughput in MPEG encoding, say, and maybe that's why little effort has been put into OSes in this vein outside of research. Or maybe it is that doing this type of OS model is hard, and nonportable (much assembly required). But in today's heightened interest in security and reliability, on hardware so fast that a few % difference in raw throughput makes little difference to most people, maybe more effort ought to be put into this and similar approaches (witness the Genode/L4/Fiasco efforts on ARMish _cell phones_).




Member since:
2006-01-26
Ultimately, I want to see more varied tests - exercising graphics (assuming there are any drivers), networking, disk I/O performance, etc. One of the things I've always read is that microkernel OSes based on the likes of Minix and Hurd are going to be noticeably slower due to all the overhead of message passing between processes, etc.
CPU intensive testing doesn't interest me as much between kernels - and even disk-based testing on a VM is sort of pointless due to host caching, etc.
When Hurd finally gets SMP support, maybe then some CPU-related tests will be interesting - to see how well a thread scheduler can cope in such an environment.
Security and stability are probably the longer-term goals of Hurd over Linux, obviously.