Optimizing: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content deleted Content added
m →‎Forum Topics: added link
Added section on cache. Needs expanding. Also doesn't make sense because I am tired.
Line 34: Line 34:


The main reason for code to become buggy or not work after adding compilier optimizations is that it removes variables, or assumes that it doesn't have to reload variables because their value isn't changed in any other code (which isn't true for most components of kernels, which are hugely interdependent). To prevent this from happening, use the [[Volatile (keyword)|Volatile]] keyword.
The main reason for code to become buggy or not work after adding compilier optimizations is that it removes variables, or assumes that it doesn't have to reload variables because their value isn't changed in any other code (which isn't true for most components of kernels, which are hugely interdependent). To prevent this from happening, use the [[Volatile (keyword)|Volatile]] keyword.

==The Cache==
{{Stub}}
The CPU's cache contains a very fast store of currently-used data. If an instruction references data that is already in the cache, it is going to be much faster than if it has to be read from general-purpose RAM.


==Links==
==Links==

Revision as of 11:35, 18 November 2008

Optimizing is a common thing in programming, but is also very important when you are programming an Operating System. One of the important things about optimizing, is that you have to know where to optimize, and where not.

When and What to Optimize

As said above, there is a time you have to optimize your code, and sometime it does not matter. There is one main place where optimizing is a very good idea: loops. Why you might ask yourself, because if you run though a loop 1 milion times, and there is just one "unnecessary line of code", then it matters a lot.

Loops are not the only places to optimize, places like:

  • Often run code
  • Graphics code
  • API code

and so on.

There is also some places where you dont need to optimize, because it would not help much. Generally, things that are not worth optimizing are things that only run once: loading an IDT, enabling paging, and crash recovery (emphasis in that case should be on stability, not speed).

This is the first step, to fast code. What does this mean? Jackscott 10:38, 18 November 2008 (UTC)

Compiler Optimization

If you're using one of the more complex compilers (such as GCC), you have available to you a lot of optimizations that can be done without having to write (or remove) a single line of code. One thing to be aware of when using compiler optimizations is that when overdone (or even done at all) they can cause previously functioning code to become buggy, or not work at all.

To use compiler optimizations in GCC, simply add the -O(x) switch to the command line when compiling, where (x) is one of the following:

Switch Use
s Optimize for size.
1 Do mild speed optimizations.
2 Do more speed optimizations.
3 Do lots of speed optimizations (not recommended).

Note that only one command line switch can be used on a single compilation, and that each level of speed optimizations does everything the level below it does, and more. For more information, read the GCC manual.

The main reason for code to become buggy or not work after adding compilier optimizations is that it removes variables, or assumes that it doesn't have to reload variables because their value isn't changed in any other code (which isn't true for most components of kernels, which are hugely interdependent). To prevent this from happening, use the Volatile keyword.

The Cache

This page is a stub.
You can help the wiki by accurately adding more contents to it.

The CPU's cache contains a very fast store of currently-used data. If an instruction references data that is already in the cache, it is going to be much faster than if it has to be read from general-purpose RAM.

Links

Forum Topics

External