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::

Notes & Annotations

Color-coded highlighting system used for annotations

📑 Annotations (imported on 2024-05-29#15:10:16)

belgaid.2022.greencoding (image) (pg. 122)

Figure 5.3: Energy consumption evolution of selected JVM distributions along versions.
Baseline:  HotSpot 8

belgaid.2022.greencoding (pg. 123)

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.

belgaid.2022.greencoding (image) (pg. 124)

Figure 5.5: Energy consumption comparison across Java benchmarks for HOTSPOT, GRAALVM & J9.

belgaid.2022.greencoding (comment) (pg. 124)

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.

belgaid.2022.greencoding (comment) (pg. 125)

Dotty benchmark required a warm-up phase of 150 seconds. After that the power difference between 3 measured JVMs were barely noticeable.

belgaid.2022.greencoding (pg. 125)

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.

belgaid.2022.greencoding (pg. 130)

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.

belgaid.2022.greencoding (pg. 134)

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.

belgaid.2022.greencoding (pg. 161)

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.

belgaid.2022.greencoding (image) (pg. 162)

Figure 6.13: Average power consumption for the idle scenario

belgaid.2022.greencoding (image) (pg. 162)

Figure 6.14: Average power consumption for Java-based languages in the idle scenario case

belgaid.2022.greencoding (pg. 163)

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

belgaid.2022.greencoding (pg. 164)

PHP, as it has one of the highest RPS with a half million RPS which got beaten only by C++ and Rust.

belgaid.2022.greencoding (image) (pg. 164)

Figure 6.16: Total request vs. average power consumption for the single query scenario (size of circles represents the number of clients)

belgaid.2022.greencoding (image) (pg. 166)

Figure 6.18: Total request vs. average power consumption for multiple queries scenario (size of circles represents the number of clients)

belgaid.2022.greencoding (pg. 170)

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.

belgaid.2022.greencoding (image) (pg. 171)

Figure 6.25: Energy consumption per request for each family of programming languages

belgaid.2022.greencoding (pg. 171)

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.

belgaid.2022.greencoding (pg. 172)

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.