The problem

Teams make code faster and call it greener, but speed and energy do not always move together. In GreenCode research, the GPU energy of a widely used AI inference engine fell by 4.7% while its speed rose by only 3%.

The fix you can use today

• Measure energy before you change anything.
• Measure again after every change, on the same machines under the same load.
• Keep a change only if it saves energy and nothing else got worse.

GreenCode researchers measure each change before and after, and keep only the ones that save energy.

Tools that help

• green-languages (GreenCode researchers): a command-line tool that measures the energy of whole programs or marked sections of code, across languages
• GreenCode Constitution profiler (profile.sh) (GreenCode researchers): a script from the Constitution tooling that measures the energy of a command from processor counters, GPU sensors and an optional smart plug, and writes the result as JSON
• Scaphandre: measures the power drawn by each process on a Linux server and exports it to Prometheus and other monitoring stacks
• CodeCarbon: a Python package that estimates the energy and CO2 of a run from hardware power and regional grid intensity
• perf (RAPL counters): Linux perf reads the processor's RAPL energy counters, e.g. `perf stat -e power/energy-pkg/`

How GreenCode helps

GreenCode helps tackle this by measuring energy before any change and after every optimisation pass, on the same infrastructure under the same load. A saving only counts if quality, security and error rate did not get worse. More on this.

Tags

#measurement#governance

Sources

• Reduced energy use (before and after, same infrastructure, same load)
• GreenCode Constitution (Kapenekakis et al., GreenAI workshop, ECML PKDD 2026): 4.7% GPU energy on llama.cpp against a 3% speed gain; re-measure and keep only what saves

All GreenCode Tech Tips