Linked by Thom Holwerda on Mon 10th Nov 2008 22:56 UTC
Saturday November 8, I received an email from someone, inquiring if I would be interested in "doing a first interview/introduction into a new operating system". We get these emails and news submissions all the time, and most of the time, "new operating system" means Ubuntu-with-a-black-theme, so we don't bother. I figured this time things wouldn't be different, but after a bit of digging around, there's a little more to it this time.
Permalink for comment 337011
To read all comments associated with this story, please click here.
poundsmack wrote:
-"and utalizes (at least on intel) multi core CPU's better than linux currently ( as up 2.6.27.5 ) as i have and develop for both. this has actualy promted me to do a bench marking of the 2 systems, both in just kernel and text mode, as well as light weight GIU's (linux with something like fluxbox, and QNX with photon)."
Well, the link was pretty pointless as it contained no comparison whatsoever. Also, while it's good that you have benchmarked it, a total lack of data aswell as how you've benchmarked them makes the statement pretty pointless and lumps it together with all the other subjective 'it feels faster' nonsense scattered across the web. By design, monolithic kernels should be faster than microkernels, is anyone disputing this? There are advantages with running everything in it's own process (stability being number one, modularity also comes to mind), but speed is not one of them. In a monolithic kernel the system call cost is setting and resetting the supervisor bit, and no overhead at all once in kernel space where all memory is accessable. In a microkernel you have to pass messages through the kernel out to different processes and they again have to respond through the same message mechanism which is alot slower than accessing process memory directly.
Now one can certainly question just how much this overhead is actually costing (I know there has been alot of improvement in the messaging and context switching which should help lower the speed penalty), and this is where some up-to-date hard data benchmarks would come in handy.
AFAIK most kernel's today that employ micro-kernel characteristics are so-called 'hybrid' kernels which uses ideas from both microkernels and monolithic kernels. Haiku (my favourite OS project uses a hybrid kernel where hardware drivers and (I think) the filesystem runs in kernel space (and thus can potentially crash the system), just like they can in a monolithic kernel. Personally I prefer speed over the chance that a buggy driver may cause havoc. If my system goes down due to a buggy driver, I will blame the buggy driver, not the system. If this happened to me often then maybe I'd sing another tune, but I seriously can't remember when I last had a system crash which was related to hardware/driver malfunction. Of course if the system were somehow responsible for keeping me alive or some such, then I'd probably go with maximum stability
Member since:
2006-01-24
poundsmack wrote:

-"and utalizes (at least on intel) multi core CPU's better than linux currently ( as up 2.6.27.5 ) as i have and develop for both. this has actualy promted me to do a bench marking of the 2 systems, both in just kernel and text mode, as well as light weight GIU's (linux with something like fluxbox, and QNX with photon)."
Well, the link was pretty pointless as it contained no comparison whatsoever. Also, while it's good that you have benchmarked it, a total lack of data aswell as how you've benchmarked them makes the statement pretty pointless and lumps it together with all the other subjective 'it feels faster' nonsense scattered across the web. By design, monolithic kernels should be faster than microkernels, is anyone disputing this? There are advantages with running everything in it's own process (stability being number one, modularity also comes to mind), but speed is not one of them. In a monolithic kernel the system call cost is setting and resetting the supervisor bit, and no overhead at all once in kernel space where all memory is accessable. In a microkernel you have to pass messages through the kernel out to different processes and they again have to respond through the same message mechanism which is alot slower than accessing process memory directly.
Now one can certainly question just how much this overhead is actually costing (I know there has been alot of improvement in the messaging and context switching which should help lower the speed penalty), and this is where some up-to-date hard data benchmarks would come in handy.
AFAIK most kernel's today that employ micro-kernel characteristics are so-called 'hybrid' kernels which uses ideas from both microkernels and monolithic kernels. Haiku (my favourite OS project uses a hybrid kernel where hardware drivers and (I think) the filesystem runs in kernel space (and thus can potentially crash the system), just like they can in a monolithic kernel. Personally I prefer speed over the chance that a buggy driver may cause havoc. If my system goes down due to a buggy driver, I will blame the buggy driver, not the system. If this happened to me often then maybe I'd sing another tune, but I seriously can't remember when I last had a system crash which was related to hardware/driver malfunction. Of course if the system were somehow responsible for keeping me alive or some such, then I'd probably go with maximum stability