When we first created Eco-CI, our goal was to help developers get a more solid grasp of how their repeated processes cost energy and carbon, and be able to put some practical numbers to that concept. It is very easy to become detached to the reality of carbon emissions when there are many layers of abstraction and conversion, as is the case with CI processes. Often what we measure is the load on a machine (via cpu-utilization), and that gets converted to a number related to the energy pull of a server (that’s off somewhere) in Joules, and while we can then convert that to an estimation of grams of CO2 emitted, even that doesn’t feel very tangible. And the less tangible the effects of our choices are, the less likely we are to think about them and change. The goal here then is to try to solidify a connection between our CI pipeline usage and the environmental impact they have.
[...]
In 2017 a paper was published in the Proceedings of 2017 ACM SIGPLAN called Energy Efficiency across Programming Languages
The paper compares different programming language on standardised algorithmical compute benchmarks and ranks them according to their energy efficiency.
[...]
Many people often critique Green Coding with two main points:
They believe the savings are insignificant, arguing that IT systems are already efficient. They find the methods and modifications required for Green Coding challenging and time-consuming to implement. However, despite these views being grounded in common software development experiences, they frequently do not hold true.
[...]
This arcticle is part of a multi-part series. Be sure to check out / stay tuned for the other parts! In this series we look at processor configuration options either from the OS side or directly in MSRs of the CPU and their effect on the power draw of the CPU. [...]
As we’ve been testing the energy use of various CI pipelines using Eco-CI, one thing we’ve noticed is that there is a large amount of variability in the results. Pipeline runs that we would expect to be more or less the same (same commit hash, running a few days in a row on the same cpu) can have wildly different results:
[...]
In this case study we will look at the ubiquitous metric CPU utilization and how helpful it is in evaluating code performance or energy consumption [...]
Turning ON deep c-states. This might increase startup-latency of some workloads, but since Cores can not only go into one fixed Turbo Boost frequency, but actually if only SOME cores go into a stronger Turbo Boost, then they can reach even higher frequencies! So if you have a workload that is single or low-threaded you can profit from extraordinary high frequencies that you might never see when all cores are always running on higher frequencies. Source: https://www.vmware.com/explore/video-library/video-landing.html?sessionid=1686331461690001FeTn&videoId=6340661293112 This arcticle is part of a multi-part series. Be sure to check out / stay tuned for the other parts! In this series we look at processor configuration options either from the OS side or directly in MSRs of the CPU and their effect on the power draw of the CPU. [...]
This arcticle is part of a multi-part series. Be sure to check out / stay tuned for the other parts! In this series we look at processor configuration options either from the OS side or directly in MSRs of the CPU and their effect on the power draw of the CPU. [...]