This documents introduces \Energyware" as a software engineering discipline aiming at de ning, analyzing and optimizing the energy consumption by software systems. In this paper we present energyware analysis in the context of programming languages, software data structures and program's source code. For each of these areas we describe the research work done in the context of the Green Software Laboratory at Minho University: we describe energyaware techniques, tools, libraries, and repositories. While in the previous century, language designer's and software engineer's main goals were to develop fast software systems, the current widespread use of non-wired computing devices is making energy consumption a key aspect not only for hardware manufacturers, but also for software developers. Software languages and their compilers provide programmers with powerful mechanisms to increase their productivity: for example, by providing advanced static type systems that reduce runtime software errors while increasing software reuse, and by offering tools that help programmers find errors (debuggers), bad smells (refactoring tools), detecting memory leaks and runtime issues (profilers), etc. All these mechanisms and tools were developed with the goal of making programming “faster” and programs run “faster”. In this document we discuss energyware as an engineering discipline to reason about energy consumption in software systems. We discuss techniques and tools developed in our Green Software Laboratory, namely, techniques to analyze the energy efficiency of 27 programming languages, to detect inefficient energy use of data structures, and to analyze software's source code and locate abnormal energy consumption. An interesting question that frequently arises in the software energy efficiency area is whether a faster program is also an energy efficient program, or not. If the answer is yes, then optimizing a program for speed also means optimizing it for energy, and this is exactly what the compiler construction community has been hardly doing since the very beginning of software languages. However, energy consumption does not depends only on execution time, as shown in the equation Energy = Time Power. A program provides a possible implementation for a given computer problem. Such a program is written in a specific programming language, it possibly uses languages data structures available in the This work is financed by the ERDF European Regional Development Fund through the Operational Programme for Competitiveness and Internationalisation - COMPETE 2020 Programme within project POCI-01-0145-FEDER-006961, and by National Funds through the Portuguese funding agency, FCT - Fundao para a Ciłncia e a Tecnologia within project POCI-010145-FEDER-016718 and UID/EEA/50014/2013. The first author is also sponsored by FCT grant SFRH/BD/112733/2015.
1:2 language libraries, and its source code implements a particular algorithm. Because there are many different ways of expressing the same algorithm within a programming language, the source code reflects the programmer’s personal coding practices (for example, by preferring loops instead of recursion, for loops instead of while loops, etc). When developing an energy efficient software system, a programmer needs to be energy-aware, where by choosing a particular programming language, data structure and algorithm the resulting program may have very different energy consumptions.
In this document we present the results obtained in defining a green ranking for programming languages 2, by analyzing the energy consumption of the Java Collection Framework (JCF) library and defining an energy-aware refactoring for Java 3, and, finally, by adapting a software’s fault localization algorithm to locate abnormal energy consumption (“energyware faults”) in the source code of a program 4.
The massive use of mobile devices made energy consumption a key bottleneck not only for hardware manufacturers, but also for software developers. When writing efficient software, programmers often ask this question: is a faster program also an energy efficient program?.
A similar question arises when comparing software languages: is a faster language, a greener one? Comparing software languages, however, is an extremely complex task, since the performance of a language is influenced by the quality of its compiler, virtual machine, garbage collector, available libraries, etc. Indeed, a software program may become faster by improving its source code, but also by “just” optimizing its libraries and/or its compiler.
In the Green Software Language Laboratory we studied the energy efficiency of the most widely
used softwa
We reused the CLBG infrastructure to define an energy-aware ranking of programming languages: We consider ten different programming problems that are expressed in each of the languages, following the exact same algorithm, as specified by CLBG. We compile/execute such programs using the state-of-the-art compilers, virtual machines, interpreters, and libraries for each of the 27 languages. We developed a framework using an energy measurement tool provided by Intel (RAPL)2, in order to measure the energy consumption when executing such programs. We used this monitoring framework to measure the energy of all executable programs included in CLBG. Afterwards, we analyze the performance of the different implementation considering three variables: execution time, memory consumption and energy consumption.
Table I contains the normalized results for energy, time and memory obtained by benchmarking the ten CLBG problems. The first column states the name of the programming languages, preceded by either a (c), (i), or (v) classifying them as either a compiled, interpreted, or virtual-machine language, respectively.
By looking at the overall results, shown in Table I, we can see that the top 5 most energy efficient languages keep their rank when they are sorted by execution time and with very small differences in both energy and time values. This does not come as a surprise, since those languages are known to be heavily optimized and efficient for execution performance, as our data also shows. Thus, as time influences
energy, we had hypothesized that these languages would also produce efficient energy consumptions as they have a large advantage in one of the variables influencing energy, even if they consumed more power on average. If we look at the remaining languages in Table I, we can see that only 4 languages maintain the same energy and time rank (OCaml, Haskel, Racket, and Python), while the remainder are completely shuffled. Additionally, looking at individual benchmarks we see many cases where there is a different order for energy and time.
Additionally, the individual benchmarks included in [Pe
There are many situations where a programmer has to choose a particular programming language to implement his algorithm according to functional or non functional requirements. For instance, if one is developing software for wearables, it is important to choose a language and apply energy-aware techniques to help save battery. Another example is the implementation of tasks that run in background. In this case, execution time may not be a main concern, and they may take longer than the ones related to the user interaction. To this end, we present in Table II a comparison of three language characteristics: energy consumption, execution time, and peak memory usage. In order to compare the languages using more than one characteristic at a time we use a multi-objective optimization algorithm to sort these languages, known as Pareto optimization.
For each ranking, each line represents a Pareto optimal set, that is, a set containing the languages that are equivalent to each other for the underlying objectives. In other words, each line is a single rank or position. The most common performance characteristics of software languages used to evaluate and choose them are execution time and memory usage. If we consider these two characteristics in our evaluation, C, Pascal, and Go are equivalent. However, if we consider energy and time, C is the best solution since it is dominant in both single objectives. If we prefer energy and memory, C and Pascal constitute the Pareto optimal set. Finally, analyzing all three characteristics, this scenario is very similar as for time and memory. It is interesting to see that, when considering energy and time, the sets are usually reduced to one element. This means, that it is possible to actually decide which is the best language.
More recently we extended the study of energyware programming languages to consider a different program repository: Rosetta Code3. While CLBG was developed with the single goal of comparing language execution time, Rosetta Code was developed with more program comprehension purposes. Our new results show interesting findings, such as [Pereira et al. 2018].
One obvious way to make a programming language more energy, memory and runtime efficient is by defining powerful compiler optimizations. Language libraries, however, also play an important role on the performance of the executable programs: modern programming languages offer a large set of libraries, which are themselves part of language, and are the building blocks when writing their programs. An important set of libraries, offered by most languages and widely reused by their programs, provides advanced mechanisms to manipulate data structures.
In the Green Software laboratory we conducted a detailed study in terms of energy consumption of the widely used Java Collections Framework (JCF) library 4. We considered three different groups of data structures, namely Sets, Lists, and Maps, and for each of these groups, we studied the energy consumption of each of its different implementations and methods. We exercised and monitored the energy consumed by each of the API methods when handling low (25000 objects), medium (250000 objects) and big (1 million objects) data sets [Pereira et al. 2016].
A first result of our study is a quantification of the energy spent by each method of each implementation, for each of the data structures we consider. Figure 1 presents the List results for population of 25k. Each row in the tables represents the measured methods, and for each analyzed implementation, we have two columns representing the consumption in Joules(J) and execution time in milliseconds(ms). Each row has a color highlight (under the J columns) varying between a Red to Yellow
4docs.oracle.com/javase/7/docs/technotes/guides/collectionns/index.html to Green. The most energetically inefficient implementation for that row’s method (the one with the highest consumed Joules) is highlighted Red. The implementation with the lowest consumed Joules (most energetically efficient) is highlighted Green.
Both RoleUnresolvedList and AttributeList contain the most efficient methods. Interesting to point out that both of these extend ArrayList, which contains less efficient methods, and very different consumption values in comparison with these two. We can also clearly see that LinkedList is by far the most inefficient List implementation. We can also see examples where a faster collection is less energy efficient. For example, looking at the AttributeList, the addAll method takes 88 milliseconds and consumes 1.0492 joules, while the set method is faster, taking 70 milliseconds, yet it consumes more energy, 1.5943 joules.
This JCF energy-awareness can not only be used to steer software developers in writing greener Java software, but also in optimizing legacy Java code. We have developed a Java data structure refactoring tool, named jStanley, which refactors Java source code when a greener collection is available [Pereira et al. 2018]. jStanley is a static analysis tool which suggests a more energy efficient (and/or performance efficient) Java collection, by statically detecting collections used in a Java project, and which methods are used for each collection. Using this information, it not only suggests a better alternative, but can automatically refactor the code with the new collections if the programmer chooses so. To see the full data on the remainder Java collections, please see [Pereira et al. 2016].
We have also executed an initial evaluation with 7 publicly available Java projects used in other research works. Figure III contains the information on the projects analyzed, including the number of tests cases and their coverage. The Analysis column displays the time spent by jStanley to detect and change the energy inefficient collections, and how many were changed. Finally, the Improvement column shows the percentage of improvement on the project’s energy consumption (total and CPU energy) and performance. By using jStanley, we were able to improve the energy consumption between 2% and 17%. The execution time has also decreased between 2% and 13%
While programming language Integrated Development Environments (IDE) have traditionally incorporated powerful advanced type and modular systems; refactoring, testing and debugging frameworks;
Project Barbecue Battlecry Jodatime Lagoon Templateit Twfbplayer Xisemele and other tools to improve software developers productivity and effectiveness, there is no concrete evidence that this trend has included techniques to optimize or even analyze source code energy consumption.
In GSL we developed a methodology to statically detect abnormal energy consumption in the source
code of a softwa
The software system to be analyzed is executed with a set of test cases, and components of such system (for example, packages, functions, loops, etc.) are instrumented to estimate/measure the energy consumption at runtime. Inefficient energy consumption, the so-called energy leaks, are interpreted in SPELL as program faults, and we adapt Spectrum-based Fault Localization (SFL) techniques to relate energy consumption to the systems source code. Our analysis associates different percentage of responsibility for the energy consumed to the different components of the underlying system. Thus, the result of our analysis is a ranking of components sorted by their likelihood of being responsible for energy leaks, essentially pinpointing and prioritizing the developers attention on the most critical red spots in the analyzed system. Thus, giving more useful information to have better support in making decisions of what parts of the system need to be optimized, ultimately helping place a new stepping stone for energy-aware programming.
Our SPELL methodology is language independent. However, to validate it with real software systems, we built a specific front-end for the Java language. Supported by this tool, our technique was able to identify potential energy leaks in the source code of concrete Java projects. Based on this identification, a set of expert Java programmers were then asked to improve the (energy) efficiency of those projects. Figure 2 shows the results of our study. For each project, we had one programmer use SPELL, one use a profiler, and one use nothing as to have a control group. The blue bars represent the energy gains percentage, while the orange bars represent the performance gains percentage. Both compared to the original, unmodified, project.
In all 6 projects, programmers using SPELL were able to better optimize the energy consumption of the analyzed Java projects, even when compared to those using profilers. The analysis of their success in doing so provided statistical evidence that the programs they ended up altering indeed consume less energy that the ones they were originally given, with an improvement, for different projects, between 15% and 74%.
This document reported the work researched and performed at the Green Software Laboratory. Our studies show that applying energyware practices when choosing a programming language, data structures, and the applied code practices of implementing one’s software do play a key role in the energy efficiency of the resulting software system. As our results show, energy optimization cannot always be solved by run-time optimization practices. The presented techniques, tools, and motivation of our GSL project is to steer programmers into developing more energy sustainable software. Thus, energyware analysis plays an important part in achieving these goals.
A more detailed look on each section’s content, tools, repositories, and other related research work can be found in the Green Software Lab’s Website 5.
SIGPLAN International Conference on Softwa
DOI:http://dx.doi.org/10.1145/3136014.3136031 Rui Pereira, Marco Couto, Joa˜ o Saraiva, Ja´ come Cunha, and Joa˜ o Paulo Fernandes. 2016. The Influence of the Java Collection Framework on Overall Energy Consumption. In Proc. of the 5th Int. Workshop on Green and Sustainable Software (GREENS ’16). ACM, 15–21.
Rui Pereira, Pedro Sim a˜o, Ja´ come Cunha, and Jo a˜o Saraiva. 2018. jStanley: Placing a Green Thumb on Java Collections. In Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering. IEEE Press.