# Minimizing Energy and Computation in Long-Running Software
## 5 Demonstration through a Real-World Example
After executing the _Energy Toolbox_ for the selected software program the following parameters were determined (It should be noted that all the measurements were made on an ARM Cortex A57 (Nvidia Jetson TX1) processor. ):  
\[ \begin{array}{l}B_{0}^{e}=0.0059,\ B_{1}^{e}=0,\ B_{0}^{c}=0.00347,\ B_{1}^{c}=0,\ K^{c}=0.097\times 1 0^{-7},\\ K^{e}=0.03345\times 10^{-9},\ b_{0}^{c}=0.752\times 10^{-6},b_{1}^{e}=6.51\times 1 0^{-9},\\ b_{0}^{c}=0.031\times 10^{-6},\ b_{1}^{c}=0.45\times 10^{-9},\ g=5\times 10^{-6}, \ L=4280.\end{array} \]  
As already mentioned, since the benchmark is highly configurable, we considered three cases of loop length (in fact, of program size). In particular, we considered the case of a small, medium, and large loop comprising \(Y=5\times 10^{5}\), \(Y=5\times 10^{6}\), and \(Y=10^{7}\) instructions respectively. It should be noted that this characterization is based exclusively on the relative size of the loops that the program contains and it is used to better facilitate the description of the present experiment. In Figure 8, the example of the program with the small loop is illustrated (i.e., \(Y=5\times 10^{5}\)). Figure 8 compares the expected execution time of the software program with and without checkpointing. Similarly, Figure 8 compares the expected energy consumption of the selected software program with and without the adoption of the ALCR mechanism. The checkpoint interval that minimizes the expected execution time (\(n^{o}\)) and the checkpoint interval that minimizes the expected energy consumption (\(n^{+}\)) are marked within a rectangle in Figure 8,b respectively. Figure 8 shows that important savings in both the expected execution time and energy consumption are achieved for software program, if the checkpoint interval is selected to be at (or close to) the values of \(n^{o}\) or \(n^{+}\) respectively computed by the mathematical model. More specifically, if \(n\) is selected to be equal to \(n^{o}\), a 74.8% gain in execution time, and a gain of 67.3% in energy consumption is obtained when \(n\) is chosen equal to \(n^{+}\). It is very clear that selecting arbitrary values for the checkpoint interval should be avoided, as this may lead to excessive increase in the execution time and energy consumption: i.e. no gain but even additional costs. As can be seen by the given example, if \(n\) is set to be less than 3 in Figure 8a, the expected execution time of the program will be higher than its expected execution time when checkpointing is not adopted. Similarly, if \(n\) is set to a value lower than 8 in Figure 8b, the expected energy consumption of the program will be higher than the expected energy consumption of the same program when checkpointing is not adopted. This indicates that frequent checkpointing may lead to the introduction of additional costs with respect to execution time and energy consumption. In addition to this, in both cases, if \(n\) is set to a value different (lower or higher) than the optimum values \(n^{o}\) and \(n^{+}\) that are computed by our model, lower than the maximum achievable gains in terms of execution time and energy consumption are achieved, leading to omission of important savings. Hence, this suggests that the arbitrary selection of the checkpoint interval should be avoided, as it may lead to omission of important savings or even introduction of additional costs, and, in turn, it verifies that there is a need for a mechanism (model) for recommending the optimum checkpoint interval. Similar observations can be made for longer loops in programs as can be seen by Figures 9 and 10. As for the previous case, these examples show that important savings in terms of execution time and energy consumption can be achieved, provided that the checkpoint interval is properly set. Here the maximum execution time savings are 73.12% and 92.21%, whereas the maximum energy savings are 77% and 94.6%, for both medium leng and long loops, respectively.