GreenCode applies AI-driven measurement and optimisation to research software and the clusters it runs on, cutting energy and cost per result without sacrificing correctness or maintainability.
View full sizeResearch computing is where software inefficiency is most concentrated: a wasteful inner loop or an idle allocation is multiplied by every core-hour a job runs. GreenCode starts from the wider context: ICT, excluding crypto and AI, already accounts for a similar level of CO2e emissions as global aviation, and data centres consume around 3% of all energy globally. Engineering simulations are singled out as costly, compute-intensive applications with their own energy, emissions and cost implications, and as a direct opportunity for optimisation.
For research software engineers this is a code quality problem: much scientific code was written to get a result under time pressure and has never been profiled for energy. For facility owners it is a capacity problem, since software savings free capacity for other jobs. For funders it is a value-for-money problem, as compute is an increasingly visible line in grant budgets and institutional carbon accounts.
GreenCode treats energy as a measurable engineering property, alongside correctness and performance. Its pipeline ingests a codebase, establishes a repeatable energy baseline, attributes hotspots to specific software artefacts, and improves the system through a closed loop of measure, optimise, validate and regression-test. Changes arrive as reviewable pull requests, so the maintainer decides what lands.
The project's state-of-the-art review notes that hardware-centred benchmarks such as SPECpower and the Green500 list, which has ranked supercomputers by performance per watt since 2007, are HPC-centric and not actionable at the level of an application or its developer. The code analysis review of benchmarks finds that even recent suites aimed at parallel and HPC code, such as PCEBench for OpenMP and MPI generation and MARCO for HPC kernels, still rely on surrogate metrics such as runtime and instruction counts, with energy absent as a direct measurement. GreenCode's contribution is to close that gap: measure energy directly, tie it to code, and verify that optimised code still produces the same output.
Infrastructure discovery comes first. Infrastructure mining tooling, extended in GreenCode to index tens of thousands of services and hundreds of thousands of dependencies, maps a running estate and rebuilds it through infrastructure as code, so that benchmarking runs on a standardised, repeatable environment.
Energy is then monitored down to process level. Virtual machine energy monitors and AI-based process-level monitoring attribute consumption to specific workloads. The review identifies GPUs and accelerators as a common blind spot in existing tools, and GreenCode plans to extend its models to include them.
Optimisation is hardware-aware. The project is investigating how the optimisation of a given algorithm is affected by the underlying platform, using GPU clusters, high-performance workstations and conventional servers, and is building a test bench that measures electrical energy, CPU and memory load. GreenCode also manages computing jobs across a network of idle or redundant devices to optimise powered resource usage.
The measures are set out in the project KPIs: a net energy saving of at least 15% per processed codebase, progression towards an "A" software carbon efficiency rating, a maintainability index above 85, stable or reduced cognitive complexity, and no net increase in quality or security issues.
A university research computing cluster is the project's research infrastructure use case. It supports general research software development and AI/ML training across a hybrid setup of bare-metal servers, a Kubernetes cluster and virtual machines. The targets are real-time resource usage dashboards, simulated resource optimisation, reconstruction of the infrastructure via IaC within one hour, and sustainability optimisations that can be implemented within a working day. The tools are designed to be infrastructure-agnostic and reusable in other academic settings.
Two smaller cases cover code. An industrial transitive closure use case takes a C++ dependency-graph algorithm that must scale from 1,000 to 100,000 nodes with cycle checking under 10 ms, and refactors it to balance performance against maintainability while documenting reusable performance principles. The other reduces the energy consumption of Badgers, an open-source Python data-augmentation library whose algorithms can be quadratic in cost.
The green DevOps and infrastructure assessment work package delivers the energy monitoring toolkit and the infrastructure discovery and reconstruction toolkit. The processing pipeline work package provides benchmarking and certification against the Green Software Foundation's Software Carbon Efficiency Rating, and automated test-case generation checks that optimised code keeps its functionality. Those three use cases supply the evaluation environments, and the same approach is being applied to engineering simulation platforms in the automotive sector.
Research facilities and software groups that want to trial the tools on their own code or clusters can get in touch.
