[Paper] CodeGreen: Towards Improving Precision and Portability in Software Energy Measurement

Source: arXiv - 2603.17924v1

Overview

The paper introduces CodeGreen, a modular platform that lets developers measure software energy consumption with high precision and across a wide range of hardware and programming languages. By separating the instrumentation (the code you insert) from the actual measurement, CodeGreen removes the usual trade‑off between accuracy and overhead that plagues existing profilers.

Key Contributions

• Asynchronous producer‑consumer architecture that decouples instrumentation from energy sampling, allowing low‑overhead, fine‑grained measurements.
• Native Energy Measurement Backend (NEMB) that independently polls hardware counters (Intel RAPL, NVIDIA NVML, AMD ROCm) and supplies a unified energy stream.
• Tree‑sitter‑based automatic instrumentation for Python, C++, C, and Java, with a simple extension path for any language that has a Tree‑sitter grammar.
• Tunable granularity via lightweight timestamp markers, giving developers control over the trade‑off between measurement resolution and runtime cost.
• Empirical validation on the Computer Language Benchmarks Game showing a correlation of $R^2 = 0.9934$ with the RAPL ground truth and near‑perfect linearity ($R^2 = 0.9997$) between energy and workload size.
• Open‑source release (code, demo video, documentation) that encourages community adoption and further research.

Methodology

1. Instrumentation Layer – Using Tree‑sitter’s abstract‑syntax‑tree (AST) queries, CodeGreen automatically inserts timestamp markers at user‑defined scopes (e.g., loops, functions, classes). This step is language‑agnostic: the same query language works for Python, C/C++, Java, etc.
2. Measurement Backend – The NEMB runs in a separate thread/process, continuously polling the relevant hardware sensors (RAPL for CPUs, NVML for NVIDIA GPUs, ROCm for AMD GPUs). Because it operates asynchronously, the application’s execution is barely perturbed.
3. Producer‑Consumer Pipeline – Timestamp markers act as “produce” events, pushing a lightweight token into a lock‑free queue. The NEMB consumes these tokens, aligns them with the most recent sensor readings, and computes energy deltas for the marked region.
4. Calibration & Validation – The authors benchmarked CodeGreen against known‑good RAPL measurements on a set of micro‑benchmarks and on the larger Computer Language Benchmarks Game suite, fitting linear models to verify that measured energy scales predictably with workload size.

Results & Findings

• Precision: Energy readings for fine‑grained regions (as small as a single loop iteration) match the ground‑truth RAPL values with an $R^2$ of 0.9934, indicating negligible drift.
• Linearity: Across a wide range of input sizes, the measured energy grows linearly with the computational workload ( $R^2 = 0.9997$ ), confirming that the asynchronous sampling does not introduce systematic bias.
• Overhead: The added runtime overhead stays under 2 % for typical workloads, thanks to the lock‑free queue and the fact that sensor polling is decoupled from the main thread.
• Portability: The same instrumentation code works unchanged on Intel CPUs, NVIDIA GPUs, and AMD GPUs, demonstrating true cross‑platform applicability.

Practical Implications

• Energy‑aware algorithm design – Developers can now profile the energy cost of individual functions or loops without rewriting code for each target platform, enabling data‑driven refactoring.
• CI/CD integration – Because CodeGreen’s instrumentation is automatic and low‑overhead, teams can embed energy regression tests into continuous integration pipelines to catch energy regressions early.
• Heterogeneous systems – Cloud providers and edge‑device manufacturers can use CodeGreen to benchmark and compare the energy efficiency of workloads across CPU‑only, GPU‑accelerated, or mixed‑hardware nodes, informing scheduling and autoscaling decisions.
• Educational tooling – The open‑source nature and language‑agnostic instrumentation make CodeGreen a great teaching aid for courses on sustainable computing or performance engineering.

Limitations & Future Work

• Hardware coverage – While the current NEMB supports Intel RAPL, NVIDIA NVML, and AMD ROCm, other emerging platforms (e.g., ARM big.LITTLE, FPGAs, specialized AI accelerators) are not yet integrated.
• Granularity ceiling – Extremely short code regions (sub‑microsecond) may still suffer from sensor latency; the authors suggest hardware‑level event‑based sampling as a possible extension.
• Dynamic language challenges – For just‑in‑time compiled languages (e.g., JavaScript, JVM‑based languages with aggressive JIT), the static AST approach may miss runtime‑generated code; future work could combine runtime tracing with Tree‑sitter queries.
• Energy attribution – The current model attributes all measured energy to the marked region, which can over‑estimate when background system activity overlaps; more sophisticated statistical models are planned.

CodeGreen opens the door to precise, portable energy profiling that fits naturally into modern development workflows—an exciting step toward greener software.

Authors

• Saurabhsingh Rajput
• Tushar Sharma

Paper Information

• arXiv ID: 2603.17924v1
• Categories: cs.SE
• Published: March 18, 2026
• PDF: Download PDF