Continuing our series of blog posts on optimizing embedded software with the aim of improving (i.e. reducing) worst-case execution times, this week we look at Native Size Variables.
Software optimization techniques which improve worst-case execution times #3: Native Size Variables
As we mentioned in the last post, using variables that are of the processor’s native size can often have a significant effect on execution times. This is particularly apparent on 8- or 16-bit devices, where manipulating 32-bit quantities has a large penalty in terms of execution time.
Example: Native size variables
Void ripple32 (Uint32 *a, Uint32 length) { Uint32 i,j,k; Uint32 tmp; for(i=length - 1; i>0; i--) { for(j=0; j<i; j++) { k = j+1; if(a[j] > a[k]) { tmp = a[k]; a[k] = a[j]; a[j] = tmp; } } } }
Execution times were obtained for two variants of the ripple sort function using 16- and 32-bit representations for all variables (see the table below) and assume a maximum array length of 10. On an MPC555, the 16-bit version was a few percent slower, whilst on an HC12, the 16-bit version was a factor of two faster.
Note that this ripple sort example is used for illustration purposes only. Other sorting algorithms with O(nlogn) operation could provide better worst-case performance over large data sets.
Function | WCET (clock ticks) | |
MPC555 | HC12 | |
Ripple 32 | 1050 | 7775 |
Ripple 16 | 1079 | 3733 |
Reduction in WCET (32 to 16-bit) | -2.7% | 52% |