Code Optimization: Effective Memory Usage
Introduction to Optimization
Chapter 1 - Program Profiling
Chapter 2 - RAM Subsystem
Chapter 3 - Cache Subsystem
Chapter 4 - Machine Optimization
On the CD-ROM
Index
List of Figures
List of Tables
List of Listings
Therefore, you should apply the following recommendations to all optimizing algorithms:
- Optimization should be as hardware-independent as possible, and it should be portable to other operating systems without additional effort or significant loss of efficiency. In other words, inline assembler functions are seldom acceptable. You should stay within the limits of high-level programming languages. Furthermore, it is best to avoid nonstandard language capabilities and extensions that only are applicable to specific compilers.
- Optimization should not increase the labor intensity of the development process (including testing) by more than 15%. Ideally, all crucial algorithms should be implemented as a separate library that requires no additional labor.
- The optimizing algorithm should provide a performance improvement of no less than 20%. Optimization methods that provide a gain of less than 20% will be considered rarely in this book. Attention will be focused on algorithms that allow performance to at least double without additional efforts from the programmer. However fantastic this might seem, such algorithms exist!
- Optimization should provide the possibility of painless code modification. Many optimization techniques can "kill" a program, because even a minor change can negate the optimization. All variables may be distributed carefully among registers, the microcode may be parallelized, and all functional capabilities may be employed. These can't compensate for the loss of the code flexibility. The execution speed of such a program can't be increased by even one clock, and its size can't be reduced by just 1 byte. Therefore, I will discuss only those optimization techniques that are not sensitive to correct changes introduced to the program structure.