In my first post about GreenIT I started an overview about the theme. There are many areas to explore. For now I'm going to explore the environment near from the developers.

Some solutions such as Carbon footprint and AWS Customer Carbon Footprint are solutions that run in the cloud after the commits. Considering that the CI/CD process has energy consumption, the developers can act before this happen and be more effective.

Unfortunately, most of the work that involves this scope is in academic articles. Also, some solutions that look like good solutions were not found on the market or in a shared code to do some testing (at least at the time of this writing), but that doesn't decrease the importance of the works.

This post I want to have an overview about the solutions and some insight about how to create a guidance/solutions to give support to developers while is coding and how to measure the energy consumption.


Interesting works

For this post, I've focused more on Design Patterns (DP) and tried to understand the impact of the choice on energy efficiency. DP are solutions to help the developers in terms of, for instance, readability and maintainability. It is not so simple in terms of performance and energy consumption.

There are many works analyzing the DPs and compare them with anti-patterns solutions. The general results is that use the patterns is better than alternative solutions in most cases. However, some DP can negatively impact the energy consumption. Here some good articles.

  • [1]: compared many of DP and detect that Observer, Mediator and Decorator consume more energy comparing the others. The authors propose to optimize the DP at the compiler considering their dynamic voltage scaling. Focus on the compiler, the code will not be changed.
  • [2] checked the Facade, Prototype, Template Method, Flyweight and Decorator. It identify that the three first patterns have negligible impact on performance and energy efficiency, the Flyweight improve both performance and energy efficiency, and Decorator get worse both criteria.
  • [3]: checked Singleton, Facade, Abstract Factory and Observer. It identify that Singleton have increased the energy consumption. The authors suppose that happen because of "in the Singleton pattern an object remains present in memory during the lifecycle of an application. This is opposed to lazy instantiation where an object is created on demand.". For the others patterns they identify a reduction of the energy consumption. Their supposition to Abstract factory is because rather than passing object references among classes, now we have a single place to get the required objects". For Observer, they believe the reason to the improvement is due to the nature of the changes made for the implementation of pattern. For Facade, the positive result seems to be in the fact it becomes the center point of interaction. This means a fewer number of temporary objects are created that are required for pass by value.
  • [4]: checked Facade, Observer, Template Method, Prototype and Decorator. The first three didn't show no difference as the last two show a large difference in time and energy. The author justify the difference by large amount of objects instantiations and method calls of the pattern-based system.
  • [5]: provides an overview for each phase of the SDLC. The highlights I can give you are: (1) programming language, raised up in the last post, where C is the best result, Java and TypeScript in the middle position (but Java being in a better position) and Phyton in the end of the line; (2) Parallel Programming that can improve the performance and energy efficiency if in the right configuration; (3) data structure, that can be impacted by the number of objects or if is using thread-safe or not, and even about the use of primitive data types, which can be more energy-inefficient comparing with objects in most of the cases while consuming less memory than objects; (4) Coding Practices, like the use of For loop with length (variable as the loop termination condition), or accessing class variables without using getter/setter functions, or the practice of static invocation (avoids the lookup overhead for calling methods through an existing object), or put the application to sleep, or select the right API, or reducing the expensive database operations, save energy; (5) refactoring techniques, that may increase or decrease the energy consumption. The technique Extend Local Variables always reduces energy consumption as the others or don't make difference or the difference is very low (Refactoring Techniques: Dead Local Variable, Non Short Circuit, Parameter By Value, Repeated Conditionals, Self Assignment Variable, Convert Local Variable to Field, Extract Local Variable, Extract Method, Introduce Indirection, In line Method, Introduce Parameter Object, Replace Method with Method Object and Encapsulate Collection). However, to work mention techniques applied to Android that save energy (Loop Unrolling, Loop Unswitching, Method Inline). This work also discuss about some tools that I list them in the next section.
  • [6]: compared the State, Strategy and the Template Method with alternative solutions and the results show that the use of the DP improve the efficiency.
  • [7]: it analyze Abstract Factory, Builder, Factory method, Prototype, Singleton, Bridge, Composite, Decorator, Flyweight, Proxy, Command, Mediator Observer, Strategy, and Visitor and conclude that the use of DP can increased or decreased the energy consumption, there are no relations between the categories and it is not possible to precisely estimate the impact of design patterns on energy consumption when only considering artifacts on design-level.


Tools

Here I split the tools I found into two categories: academic and testable. It is an informal category that I defined based on my experience to try to apply or just test them. The tools classified as academic are the tools that I found only the article but not the code or even if the code seems deprecated (long time without commits). Most part of those tools were mention in [5].

Academic:

  • GREEN [8][9][5]: It is a framework focused on Computations and loop termination that try to optimize expensive loops and functions considering user-defined Quality of Service (QoS) requirements. It has as output a new version of the program.
  • Chisel [10][11][5]: Focused on Computational kernel operations : acts in an automated manner by selecting approximate kernel operations that result in energy, reliability, and accuracy optimizations. Chisel is utilizing the approximate memory of its running platform to increase energy savings by sacrificing some of its quality output.
  • Parrot [12][5]: Focused on Optimizes regions of imperative code. It is a neural network model that identifies imperative code regions and offloads them to neural processing unit, instead of CPU, to increase energy and run-time performance.
  • Axilog [13][14][15][5]: Focused on Source code parts. It is a Verilog extension composing brief and high-level annotations for full control and governance of approximate hardware.
  • EnerJ [16][17][18][19][20][5]: Computations, Data Storage, and Algorithmica: By declaring variables and objects as approximate, EnerJ maps them to approximate memory and generates low-cost energy code by using approximate operations and algorithms
  • GreenAdvisor [22][23][5]: (Android) is a profiler system calls that predicts behavior, run-time performance, and energy-related modifications of an application. To predict energy-related changes, GreenAdvisor compares the number of system calls on a current version of a software and its previous one. GreenAdvisor compares the energy consumption of different versions of a product and points out the system calls that caused the change.
  • eLens [24][25][26][5]: estimates energy consumption via program analysis and per-instruction power modeling. The authors use program analysis to obtain execution-related information such as bytecode or API calls from various smart-phone components (e.g., CPU, RAM, GPS, 3G). eLens provides energy measurements at various levels of granularity: application, method, class, path, and source code lines.
  • Jalen [27][28][29][5]: Java-based agent for software energy monitoring at the source code level. Jalen measures selected methods and classes. Additionally, it provides measurements on explicit hardware components (e.g., CPU and HDD) and estimates the energy consumption of software by analyzing executed Java instructions.
  • PEEK [30][31][32][33][34][5]: PEEK fully automates energy measurement tasks and suggests program-code improvements at development time by providing automatically generated energy optimization hints. Our approach is based on a combined software and hardware infrastructure to automatically determine energy demand of program code and pinpoint energy faults, thereby integrating seamlessly into existing software development environments. PEEK’s energy-associated hints are related to power management mechanisms (e.g., sleep state, idle state, program-code logic, libraries, and compiler). PEEK analyzes source code at function granularity
  • SEEDS [35][36][37][5]: a decision support framework that create instances of an application under development using different queue data structures, to find the most energy efficient ones. SEEDS’ suggestions are limited to Java Collection Libraries (JCL), algorithms, or refactoring parts of the source code. SEEDS offers to developers the possibility to set a code block range for analysis.

Testable:

  • PowerAPI [38][39][5]: real-time monitor in process-level energy consumption. Jalen has PowerAPI as the core component for extracting energy measurements.
  • Running Average Power Limit (RAPL/jRAPL) [40][41][42][5]: monitors and controls energy consumption via performance counters by exposing kernel subsystems, hardware devices, and device driver information. jRAPL use Java. Some tools use this RAPL as a core to measure the energy.
  • top[43][44]: it is a command line tool that list all running processes on the system doing a periodic measurements. Similar to Activity Monitor, a tool with graphical interface to MACOS, you can see data as CPU, memory and power.
  • ioreg [45][46]: The I/O Registry is a dynamic database that describes a collection of “live” objects (nubs or drivers) and tracks the provider-client relationships between them. With this native tool is possible collect information about energy consumption.
  • EcoAndroid [47]: IntelliJ plugin for android aplication. EcoAndroid suggests automated refactorings for reducing the energy consumption of Java Android applications. It is based on the idea of energy pattern (Dynamic Retry Delay, Push Over Poll, Reduce Size, Cache, Avoid Graphics Animations).


Hands-On

A good starting point is to explore the project Energy Efficiency in Programming Languages done by Green Software Lab. It is a good project to compare the energy efficiency between programming languagesthat. The code is available and give the possibilitiy to test and compare 28 different languages in different scenarios. It uses the Intel’s Running Average Power Limit (RAPL) tool as the core to estimate the energy consumption.

If you have an Intel you just need to do a simple configuration and it's ready to test locally. But if you are using a MAC like me you need other steps to do.

This article has a good discussion about how measure the energy in MAC. The Activity Monitor tool is available in MACOS. It is a graphical tool where you can see the values of the PC. A similar tool is the top that you can have similar values but using command line.

A second alternative or complementary is the ioreg (I/O Registry). This post has a good discussion about how to measure the energy consumption using ioreg in MAC.

In my test using that repository I tested use ioreg and top calling command line by app. installed a lib of ioreg to facilitate my work.

$npm install ioreg

Here I'm using ioreg and top but it doesn't mean they are dependents. It's only a test to check the outcomes.

Doing a simple test

For a simple test, a portion of the the project "Energy Efficiency in Programming Languages" was extracted. The goal is not test the language or the DP but see how to measure the energy considering a MACOS. So, for this test was used ontly four Benchmark from TypeScript.

For that, I extracted the code for another project using NestJS, and my calls are done by a controller. Furthermore, I did my tests using top and ioreg. As I said before, my idea is just to run the tools to catch the values and have my first experience doing that activity. Even so, the logic is the same: have a starting point to make it step 0 and start to count the values and have a final step to exposes the values.

Here is the core to catch the values. It's not the best solution but it works to the goal. The complete code you can see here.

Result

The values got in the end of the process was the average from top and one execution of the ioreg. The image is regarding the execution of the binarytrees but you can do the same with the others benchmarcks implemented.

Conclusion

There are some trade-offs when we are coding in terms of energy efficiency. The good parts is in terms of Design Patterns we can use it without too many restrictions. Only pay attention in some of them like Decorator, observer and mediator.

As a good practices, some point can help to improve the efficiency as the Parallel programming. It's not a silver bullet but can help in some scenarios.

How to measure is one of the trick points because it influenced by the CPU and OS.

This post tried to do an overview about the theme and some ideas how to check the energy consumption. Next post let's put everything together.


Reference