[aha]

It looks like the browser performance in BB10 is, if not the best, at least among the best the market can offer right now. And we know BB10 has no lag at all in its UI. But are these two observations sufficient enough to prove micro kernel based QNX's efficiency in task scheduling?

One counter point would be, the latest Android Jellybeans OS seems to be all around buttery smooth too (haven't used one myself but read quite a few posts claiming this). The hardware specs of these Jelly bean devices are not really supieror than BB10, so,

Are these buttery smooth experiences on BB10 and Jelly Bean devices purely the result of advancements in hardware specs? Does micro kernel OS indeed have an edge over non micro kernel OSs?

[aha]

Anyone????

[pb1379]

Are these buttery smooth experiences on BB10 and Jelly Bean devices purely the result of advancements in hardware specs? Does micro kernel OS indeed have an edge over non micro kernel OSs?

No, the smooth experience doesn't only come from improved hardware, though it obviously helps. The comparably huge amounts of memory in today's devices compared to the beginnings are helping Android and make BB10 only possible at all. Raw CPU/GPU power is not that much a topic in daily business, unless you're using hungry apps, like games, of course.

For Android, it's mainly severe optimizations of the application frameworks.

For BB it's a fresh start with an architecture that wouldn't have been possible/suitable on these old devices.

The QNX micro kennel architecture isn't that important to smoothness, but the fact that it favours natively compiled apps, which not only preform better, but also have less overhead and no lags through garbage collection.

Sent from my XT925 using Tapatalk 2

[pb1379]

Does micro kernel OS indeed have an edge over non micro kernel OSs?

It does have advantages, besides the academic elegance:

1. It allows for better tailoring to specific needs, as nearly all components are plug and play modules outside the micro kennel, thus allowing the inclusion of just the modules you actually need. It also allows to easily provide variants of modules. For example, process scheduling in a car control system probably should work differently than in a toaster. It's much more difficult to maintain that independence/variance in monolithic kennels.

2. Above dynamics can even be performed at runtime, should it be desired.

3. Micro kernels are much better suited for real time systems, as the nucleus is a small, fast, and transparent little piece, governing the rest of the bulk, thus can react much faster - within the tight constraints - to events. Again, you can achieve that with a monolith, too, but it's much harder.

Sent from my XT925 using Tapatalk 2

[aha]

Is there a way to quantify this advantage? If we run an android app on BB10, would the performance gain more than canceled by the overhead brought by the extra layer -- Android runtime?

And when they are talking about upgrading android runtime to support Jelly Bean, would that bring in performance gain, or just Wider app supports?

[sclitheroe]

3. Micro kernels are much better suited for real time systems, as the nucleus is a small, fast, and transparent little piece, governing the rest of the bulk, thus can react much faster - within the tight constraints - to events. Again, you can achieve that with a monolith, too, but it's much harder.

This is highly dependant on the hardware the kernel is running on. A microkernel based system incurs many more context switches than a monolithic kernel design, since so many OS services and API's run outside the microkernel thread or process itself and communicate via IPC. If your processor isn't efficient at context switching between various threads/processes that make up a microkernel based OS, it will actually be slower (but more modular, as you noted for other benefits)

[pb1379]

This is highly dependant on the hardware the kernel is running on. A microkernel based system incurs many more context switches than a monolithic kernel design, since so many OS services and API's run outside the microkernel thread or process itself and communicate via IPC. If your processor isn't efficient at context switching between various threads/processes that make up a microkernel based OS, it will actually be slower (but more modular, as you noted for other benefits)

I completely agree with you that OVERALL performance of a micro kernel architecture must be lower - for the exact reason you pointed out. However, the penalty isn't as big as it might seem at first, as context switches at this level are much cheaper than user process switches. Also, it is probably annihilated by the advanced optimizations that are humanly possible in such an architecture. The QNX micro kernel, if I remember correctly, is some four or so KB of code optimized over more than a decade, by now they probably squeezed out every ms possible. I wouldn't want to try that kind of optimization throughout a complete monolithic kernel, keeping track of all the dependencies. It isn't impossible by no means, there are commercial monolithic real time systems, I just wouldn't want to be the poor one who has to maintain them.

But actually, that wasn't what I meant, I was referring to the ability to react faster to events that need real time treatment, not overall performance.

Sent from my XT925 using Tapatalk 2