OSDev.org

berkus wrote:

JamesM wrote:And yet, you don't want that because you're unlikely to have SSE enabled in your kernel, right? (extra 512 bytes to context switch)

Not in the kernel (unless your kernel is very computationally intensive), but there's also userspace.

/me looks at your reply, then up to the thread title, then back to your reply again.

Hobbes wrote:

LindusSystem wrote:Using special keywords such as 'register' and 'inline' ,etc

Just to add a little note: for optimization it is not wise to use "register". The compiler probably knows better than you do which variables should be "register" and which shouldn't. The "register" keyword is a left-over from times when optimization was in its infancy.

Actually, C++11 specifies the "register" keyword as "deprecated".

Let's assume you want to handle USB devices at "wire speed" and you are running on a Intel Core i5 Sandy Bridge beast.

Basically, you can write the fatest kernel you will be able to achieve your goal: a USB device is awfully slow compared the CPU.

Let's assume you want to have a very fast disk access, at controller speed: a disk device is awfully slow compared the CPU.

Same answer.

Let's assume you want to implement a fast smart text search algorithm on data on the disk.

Same answer: the performance gains will be obtained in the memory search algorithm

Let's assume you want to respond as fast as possible to an event (IRQ).....

You have to tell what the kernel is made for.

As an example, I am doing a kernel optimized for network packet handling. The key performance factors are NOT how fast it can handle interrupts (the best is to have 0 interrupts), but rather how packet buffers are allocated/freed/handled/dupplicated. Optimizing function call by inlining delay is about working on the 10th decimal of the total time to handle a packet.

Hi,

In my opinion, there's only 3 types of optimisations. The first type is optimising "how" (choosing better algorithms). For a simple example, choosing to use a binary search instead of a linear search is a "how type optimisation".

The second type is optimising "when". For example, if a hard disk is reading/writing data as fast as it can, then you don't want something important (e.g. reading/writing to swap space) to have to wait for something much less important (e.g. background file system checks). This means things like disk drivers, network cards, USB controllers, etc need to know how important thing are (IO priorities) so they can make sure more important things happen sooner and less important things don't get in the way.

The third type of optimisation is micro-optimisations. The compiler should do most of this for you.

In my opinion, there's also 2 categories of optimisations - premature optimisation (e.g. when you can't be sure that it's an effective use of your time, including code maintenance) and required optimisation (e.g. when you know that failing to add something like IO priorities to your OS design and APIs is going to cost you a lot of extra work rewriting existing code later on).


Cheers,

Brendan