Green coding : an empirical approach to harness the energy consumption of software services
Status:: 🟩
Links:: Energy-efficient Software
Metadata
Authors:: Belgaid, Mohammed Chakib
Title:: Green coding : an empirical approach to harness the energy consumption of software services
Date:: 2022
URL:: https://theses.hal.science/tel-04074973
DOI::
Belgaid, M. C. (2022). Green coding: An empirical approach to harness the energy consumption ofsoftware services [Doctoral dissertation, Université de Lille]. https://theses.hal.science/tel-04074973
The ICT sector is claimed to account for 2% of global emissions. Even though this might seem like a small number, the success of ICT technologies will always lead to more greenhouse gas emissions. In 2019, the number of data centers worldwide was 1.5 million, which is expected to reach 2.5 million by 2025. In this situation, lowering the emissions from the ICT sector depends on reducing the amount of energy used by data centers. There are three main methods to achieve this goal: improving the hardware's efficiency, lowering the cooling systems' energy consumption, or decreasing the energy consumption of the servers themselves. This thesis focuses on the last approach, which I believe is the most affordable one, as it does not require any physical changes to data centers. My goal is to assist developers in making more eco-friendly software services by providing them with tools and guidelines to create software that runs on servers while consuming less energy. To do so, I decided to pursue an empirical approach consisting of three steps: test, measure, and optimize.The reason for such a decision is to follow the rapid pace of the software industry. In fact, the software industry has one of the fastest growth rates, which makes it challenging to keep up with the newest technologies. So, instead of just reporting my insights, I gave practitioners the means and protocols to allow them to test their hypotheses. I believe that some of the insights shared as part of this thesis might already have become obsolete when published.Due to the urgency of the climate change issue, I decided first to harness the most popular yet energy-hungry programming language, Python. Therefore, I started by analyzing Python's code's energy behavior during its most commonly used cases. Then, I provided a non-intrusive technique to reduce its energy consumption. After that, I extended this strategy to another programming language famous for its legacy code base, Java, to show that we can still reduce the energy consumption of already running applications without paying a considerable price.Finally, I adopted a more systemic approach. Instead of optimizing one single application, can one reduce the energy consumption of the data center as a whole entity? Thanks to the micro-services architecture, one application can be constructed using many services, each independent of the other. This type of architecture releases us from the bond of adopting a single programming language as the monolithic application does. And with this, one can use multiple programming languages and take advantage of the strengths of each one for a specific scenario. The last chapter analyzed the energy behavior of several programming languages regarding web services while opening a new path toward sustainability within timeless applications.
Notes & Annotations
Color-coded highlighting system used for annotations
📑 Annotations (imported on 2024-05-29#15:10:16)
Figure 5.3: Energy consumption evolution of selected JVM distributions along versions.
Baseline: HotSpot 8
Figure 5.5 further explores the comparison of energy efficiency of the JVM distributions per benchmark. One can observe that, depending on the benchmark’s focus, the energy efficiency of JVM distributions may strongly vary. When considering individual benchmarks, J9 performs the worst for at least 6 out of 12 benchmarks—i.e., the worst ratio among the 4 tested distributions. Even though, J9 can still exhibit a significant energy saving for some benchmarks, such as Avrora, where it consumes 38% less energy than HOTSPOT and others. Interestingly, GRAALVM delivers good results overall, being among the distributions with low energy consumption for all benchmarks, except for Reactors and Avrora. Yet, some differences still can be observed with HOTSPOT depending on applications. The newer version of HOTSPOT-15 was averagely good and, compared to HOTSPOT-8, it significantly enhances energy consumption for most scenarios. Finally, Neo4J is the only selected benchmark where HOTSPOT-8 is more energy efficient than HOTSPOT-15.
Figure 5.5: Energy consumption comparison across Java benchmarks for HOTSPOT, GRAALVM & J9.
GraalVM requires more average power than HotSpot and J9. However, the higher power usage for GraalVM helped in achieving a high amount of requests, but also the fastest execution of every request, which was 40% faster on GraalVM. Thus, GraalVM was more energy efficient, even if it uses more power.
Dotty benchmark required a warm-up phase of 150 seconds. After that the power difference between 3 measured JVMs were barely noticeable.
To answer RQ 1, we conclude that—while most of the JVM platforms perform similarly— we can cluster JVMs in 3 classes: HOTSPOT, J9, and GRAALVM. The choice of one JVM of these classes can have a major impact on software energy consumption, which strongly depends on the application context. When it comes to the JVM version, the latest releases tend to offer the lowest power consumption, but experimental features should be carefully configured, thus further questioning the impact of JVM parameters.
Globally, we conclude through these experiments that keeping the default JIT configuration was more energy efficient in 80% of our experiments and for the 3 classes of JVMs. This advocates using the default JIT configuration that can often deliver near-optimal energy efficiency. Although, some other configurations, such as using only the C1 JIT or disabling the JVMCI could be advantageous in some cases.
To answer RQ 2, we conclude that users should be careful while choosing and configuring the garbage collector as substantial energy enhancements can be recorded from one configuration to another. The default GC consumes more energy than other strategies in most situations. However, keeping the default JIT parameters often delivers near-optimal energy efficiency. In addition, the JVM platforms can handle differently multi-threaded applications and thus consume a different amount of time/energy. Dedicated performance tuning evaluations should therefore be conducted on such software to identify the most energy-efficient platform and settings.
Idle behavior This part will treat average power behavior when the framework is in a rest mode. Figure 6.13 presents, a density plot for each family. As one can notice at rest, most families consume between 20 and 40 Watts, and 6% of the compiled language frameworks consume less than 15 Watts. However, 50% of Java solutions tend to consume around 50 Watts, which makes it the most greedy family.
Figure 6.13: Average power consumption for the idle scenario
Figure 6.14: Average power consumption for Java-based languages in the idle scenario case
In Figure 6.16, each run is represented by a circle, and the size of the circle indicates the number of concurrent clients: The smaller the circle, the fewer clients. On the one hand, one can notice that compiled languages are the most efficient in terms of performance, despite their average energy consumption. Moreover, there is no significant change in the average power consumption when we increase the number of concurrent clients. On the other hand, the JVM-based frameworks tend to consume the most energy while reporting the same performance as the .Net-based ones. Finally, the interpreted languages lack performance while keeping low power, except for
PHP, as it has one of the highest RPS with a half million RPS which got beaten only by C++ and Rust.
Figure 6.16: Total request vs. average power consumption for the single query scenario (size of circles represents the number of clients)
Figure 6.18: Total request vs. average power consumption for multiple queries scenario (size of circles represents the number of clients)
This section presents a study on several web frameworks’ performance and power consump- tion. To do so, we used the TechEmpower17 benchmark suite, which is a set of tests that measure the performance of several web frameworks. We tested 261 frameworks using 7 scenarios. We found that Java-based frameworks are the most power-consuming, while the complied ones are the most efficient in terms of performance. Moreover, PHP remains one of the most efficient frameworks in terms of performance and energy despite being an interpreted language. This behavior is mainly due to the optimization done on the Zend engine18 to fit the website’s requirements.
Figure 6.25: Energy consumption per request for each family of programming languages
To summarize our findings, we present in fig. 6.25 a comparison of the energy consumption per request for each scenario. While we have seen in the previous results that Java-based frameworks depict the highest energy; they still provide greener requests compared to the interpreted frameworks; this is mainly because their interpreters report lower performances.
Our studies revealed the absence of a clear winner in terms of energy efficiency. However, when we take into consideration the cost of a single request. C++ and Rust were the topranked, hence assessing the work done by Pereira et al.. On the other hand, Unlike the results shown in the paper [117], PHP exhibits a higher performance while keeping a high power consumption on average. This result is due to the nature of PHP language, which is dedicated to the web and not general-purpose programming. While most of the frameworks consumed around 100watts, Java-based frameworks consumed around 220watts. This made Java one of the most energy-consuming in the context of online services, especially when considering the periods with low traffic.