Estimating Energy Consumption of Applications
The mobile application market has grown enormously during the past years. An increasing amount of applications need to run on devices with limited energy supply, and users are frequently critical of the short recharge cycles. Software can be written with a decreased energy footprint as a primary goal. However, developers cannot simply guesstimate the efficiency of their program. Furthermore, measuring the actual power draw devices is not easily integrated into the development cycle. Therefore, one focus of recent research has been on finding models to analyse the energy consumption of a program. They can make use of benchmark tests, models of processor architecture as well as logical reasoning methods to predict execution paths through the code. This article will focus on efficient approximate methods leaving out, for example, testing out the code in a modified emulator of a device, as that is very similar to performing practical measurements.
Types of energy analysis
Dynamic analysis involves testing a program on actual hardware. While the results may be of very high accuracy for common execution paths, the testing takes up a large amount of time (1: p. 5f.). Furthermore, in contrast to the functionality of the code, the energy efficiency of edge cases and sparsely used branches can often not be unit tested outside the context of the entire program. Therefore, observations will mostly describe average use cases and could miss exceptional sources of errors or bottlenecks. This method should preferably be used as a comparison or benchmark for other models, as it does not integrate well into the continuous development process. Safety-critical systems should still thoroughly test code in practice, as large run times can be neglected there.
Static analysis is used to approximate the energy consumption of a program without having to run it in practice. The method is platform independent and can be executed for example on the programmer's computer. Static analysis requires models of the power usage of the processor for different tasks. The number of times these computational units are executed is calculated with an intermediate, abstract representation of the code such as bytecode. The accuracy can be improved with more detailed reference data as well as logical reasoning about the program to predict the likelihood of certain execution paths (p. 6). While this method can only provide estimates of the energy consumption, its easier usability by programmers during coding and the independence from hardware are its biggest advantages.
Approximation with system level data
Modern computers provide a large amount of information about their current usage. Those measurements include the current utilisation of the processor and how much CPU time is being spent on execution, waiting and interruptions. Furthermore, the file system, memory and internet connection can also be monitored. Researchers from the National University of Singapore and the Florida International University (2) have used this data to experimentally determine that for example the utilisation and idle time have a high correlation with the energy consumption and increase/decrease it respectively. With a supervised learning method, they were able to create a model which takes in the parameters and estimates the power usage with an accuracy of 95% (p. 94). While it still uses practical measurements in the beginning to calibrate their program, their method can effectively estimate the energy consumption of an entire Linux based system not limited to just the CPU afterwards. However, this method is still classified as dynamic analysis, because even though it does not require special measuring hardware after calibration, applications still need to be run and tested manually to assess their efficiency. Furthermore, the approximations can only be made on system or process level, meaning that only the footprint of the entire program and not a single method or line of source code can be measured (p. 101).
Two researchers from the University of Alberta (3) have expanded similar functionality to Android™ with the GreenOracle application. They applied four machine learning algorithms to energy consumption data from 24 programs with 984 unique versions in total. After collecting system call traces and CPU utilisation data of test cases, the power consumption of the Android application can be estimated with an error of mostly less than 10% using their trained model (p. 49). While this approach still needs the practical execution of the program for the estimations, the necessary data could be collected during the regular testing of the development cycle. It enables a short but not instant feedback loop for programmers between the compiled version of the code. Therefore, the authors suggest that their software could be used to find so-called energy bugs, which cause unexpected reduced battery life, or to automatically test and rank mobile applications based on their energy efficiency (p. 56).
One further approach uses the fact that computers operate in different power states and frequently switch between them to reduce the amount of energy being consumed. By capturing when and how often those transitions occur, a coarse approximation of the power usage can be made. This method, however, again does not give programmers information about the particular piece of code they are working on and needs to be tested on hardware. Furthermore, the approach is dependent on the hardware implementation of power states and, therefore, not portable.
Program analysis
In computer science, it is often required to prove a property of an algorithm or procedure. Static program analysis is a collection of methods to formally and often partly automatically reason about the functionality, correctness and performance of a program. The code is often transformed into an abstract representation to check, e.g. the type system, data and control flow. To estimate the energy consumption of simple code, the control flow is of high importance, as this example shows (1: p. 10):
void main () {
// Counter variable x set to 0
int x = 1;
// Loop executes while x <= 10
while (x <= 10) {
// The radio is only switched on in iterations 4 and 10
if ( x == 4 || x == 10) {
radio_on();
} else {
radio_off();
}
// Couter variable x incremented
x++;
}
}Even though the entire loop is executed ten times, the specific radio_on function is only called twice. Program analysis can, therefore, be used to express which code is executed how often without having to test it.
Source code level estimates
At the Radboud University Nijmegen, Stein Keijzers (1) extended the static energy analysis tool EcaLogic to enable the estimation of the power consumption of a program written in a subset of the C language. It first compiles the source code, which has been annotated to include information about for example the bounds of loop execution and energy usage of specific external functions, to an abstract syntax tree. The tree is converted into a Java bytecode which represents the functionality and consumption as hardware component models (p. 45-50). To obtain the bounds of the energy consumption, the bytecode is run together with the tool, which uses Java's reflection feature to perform the analysis. Because of the use of annotations, the granularity of the estimates can be defined on a program, method, branch or code line level (p. 50). Even though the various manual steps between writing the source code and obtaining the estimate take up additional time, EcaLogic-C could still provide useful information about the energy efficiency after each compilation. However, the prerequisite of specific annotations makes it impossible to use the tool without previous manual reasoning, e.g. about the termination of loops.
eLens is a program that was developed by four researchers from the University of Southern California (4). It consists of three components that use a description of the typical workload of a Java program, its bytecode and a platform-specific system profile to generate annotations for the source code which can be viewed by the programmers in an IDE. First, there is the Workload Generator, which uses the description of, e.g. user interactions and the bytecode to information about the execution paths of the program as well as their utilisation. It is combined with the system profile in the Analyser which estimates the amount of consumed energy with an average accuracy of 90% (p. 92). As not all calls to external functions have the same efficiency, the profile is used to define such high-energy events which the researchers showed in their extension vLens (5). Lastly, the Source Code Annotator, which is implemented as a plugin for the Eclipse IDE, combines the path information and energy estimates to create visual feedback for the programmers. Those annotations can be at an individual source line level or summarise code paths, methods or the entire program. Apart from this intuitive way to inform developers about the power consumption of their code while they are working on it, the major advantage of eLens is its portability. System profiles and bytecode can be obtained for most combinations of compiled languages and operating systems. Therefore, eLens could be used not only in the researchers' implementation for Android in Java (p. 84).
Conclusion
Dynamic and static energy analysis models are an important opportunity for developers to estimate the energy consumption of their programs. While platform-dependent testing provides the most accurate results for average use cases, approximations based on system level data and estimates based on the bytecode of the application are alternative approaches, which can be integrated into the continuous development cycle more easily. However, most of the tools developed by the researchers do not reach the public, or their maintenance is stopped after some years as in the case of eLens (6). To enable intuitive energy-aware programming, it is therefore important for developers to adopt and help maintain those tools. Furthermore, IDEs should integrate static or dynamic energy consumption analysis tools by collaborating with the researchers.