The final blog post in our series on optimizing embedded software with the aim of improving (i.e. reducing) worst-case execution times summarises the techniques outlined in previous posts.
Software optimization techniques which improve worst-case execution times #18: Summary of Techniques
In this series we’ve looked at a variety of techniques for optimizing worst-case execution times, giving quantitative results. Here is a summary of the techniques.
Technique | Reduction in WCET | |
MPC555 | HC12 | |
Native variable size | -2.7% | 52% |
Function in-lining | 38.8% | 19.6% |
Loop jamming | 33.3% | 29.7% |
Hoisting loop invariants | 15.7% | 27.9% |
Loop unrolling | 44.5% | -3.5% |
Look-up table v. switch | 30% | 74.3% |
Single path copy | 77.7% | 88.2% |
Removing average case optimisations | 9.3% | 2.2% |
Re-positioning code | 41.6% | 41.3% |
*Note that the loop unrolling optimisation example resulted in an increased execution time on the HC12. This was due to the fact that the code was optimised assuming that the processor could implement ‘shift by a number of bits’ efficiently. As the HC12 only has instructions to shift by one bit at a time, the “optimised” code actually resulted in an increased execution time. For other examples, loop unrolling on the HC12 is highly effective (e.g. the single path copy resulted in an 8-fold reduction in execution time).
The loop unrolling example serves to illustrate an important point. The only way to determine if a particular optimisation is effective is to use quantitative analysis, obtaining worst-case execution times for the code before and after optimisation.