Upon this page you will find:

• Choosing the Correct Algorithm
• Good Implementation
• General Notes
• Getting Down to Assembly

It is important to select as efficient of an algorithm as you are able to when implementing software, especially in speed critical sections of your code, though also in other parts of your code. The best optimizations come from the correct choice of algorithms for every part of your code, without exception. Though complete optimization involves more than just the algorithm, as other things can help by up to 20%, even once you already have the correct algorithms.

It is poor practice for a compiler to try to compensate for poor input. Asking to compiler to compensate just makes the compiler run slower, be bigger, and causes more trouble. It is much better to have the programmer give as good of input as they can, which should improve over time. Compilers should be as small and simple as reasonable, doing a little optimization, though not overdoing it.

Programmers learn to produce more efficient code over time, this is part of writing code. There is never an end to learning to do better, for anyone that truly enjoys coding. Every iteration will bring better results, as the programmer learns to do better with each iteration. Thus any true programmer has no problem scraping existing code and doing a ground up rewrite to improve the resulting project.

It is common that there are many means of accomplishing a given task when writing software. Sometimes the differences between two methods is quite small, though may make a bigger difference than seams rational. The method of accomplishing the task at hand is known as the Algorithm being used.

There is no better single optimization than choosing the best algorithm to use for a given task. Even at this we should always to strive to learn algorithms that are better for given tasks, as well as learning which algorithms are better for some tasks and worse for other tasks. The evolution and continuing descovery of new algorithms is an art that will continue forever more.

At times we must find a balance between decisions of what algorithm to use. In some cases we need an algorithm that both reduces memory usage and is faster, then we may need a balance that is not perfect either direction. Sometimes a deadline prevents us from finding or inventing the absolute best known for the task at hand. No matter what the ideal of KISS should be maintained (Keep It Simple, Silly).

Once you have a good algorithm you need to implement it well to produce good results. Remember the implementation rules when choosing what algorithm to use, as sometimes this can make a difference between two closely matched algorithms. The corect implementation of the correct algorithm can make for extreme improvements in performance overall.

Most of the more important rules for implementation are easy to remember while coding. These include things like keeping loop invariant operations out of the loop, and the other obvious things. Even things like knowing when to unroll a loop, or inline code, are fairly easy to remember.

Then there are some details of implementation that may not be quite so obvious, often depending on particulars. Some may be specific to the language being used. There may be some implementation detail that vary from one compiler to another, these can be difficult to pin sometimes.

Even when working in an High Level Language, you need to take into consideration details of the target architecture for the best possible implementation on the target. Some details of some CPU's may make the choice of what to do vary from other CPU's, even the Memory architecture can make a difference on this kind of choice. The target Operating System can even effect how the implementation effects performance. It is often quite surprising how much of a difference can be made by keeping the target in mind while writing optimal High Level Language code.

There are things that can not be covered by the normal categories of optimization. For example the rules specific to optimizing interpreted BASIC. These exceptional areas are what this section is for.

Ever since the early 1990s many have repeatedly said that no one can beat a 'modern compiler' with hand written assembly. With each generation of 'better optimizing' compiler there are Assembly Language coders that prove that hand written assembly language can still outdo 'modern compilers', by outperforming the compiler for various tasks. The result is useless compilers that are way too big and slow, at compiling, for the small amount of gain on optimization over earlier much simpler compilers. Part of moving forward is learning not to expect the compiler to be perfect, as it never will be, and the compiler needs to not be so out of hand.

When programs are written in assembly language there may be a need to optimize them in assembly. When the compilers output is less optimal than what is required, it may be appropriate to tune the output in Assembly. If writing a peephole optimizer, understanding more optimal assembly is needed. While writing the code generator of a compiler, the means reasonable to create fairly optimal assembly will need to be understood.

There will always be tricks not yet discovered, or other things not yet known, about how to produce the best code in assembly language. For all the tricks not yet thought of, we push forward, experiment with ideas, and always learn a little more as we go. No matter how far we get there will always be more to learn, even if we persist on the same exact version of the same CPU this is still a truth.

For those that have the view of a logical mind, Assembly language programming is very much fun. This is especially true of programming in Assembly Language for the ARM CPU, as well as for the 68K series. Then there is the eternal enjoyment of always learning more and more about how to do better with our code.