Laurence TrattOct 10, 2024
An interesting paper from @emeryberger et al., showing that, in contrast to prior work, (in my words) energy use across programming languages is a proxy for how long a program takes to execute, and that other factors don't meaningfully affect energy usage. https://arxiv.org/abs/2410.05460
It's Not Easy Being Green: On the Energy Efficiency of Programming Languages

Does the choice of programming language affect energy consumption? Previous highly visible studies have established associations between certain programming languages and energy consumption. A causal misinterpretation of this work has led academics and industry leaders to use or support certain languages based on their claimed impact on energy consumption. This paper tackles this causal question directly: it develops a detailed causal model capturing the complex relationship between programming language choice and energy consumption. This model identifies and incorporates several critical but previously overlooked factors that affect energy usage. These factors, such as distinguishing programming languages from their implementations, the impact of the application implementations themselves, the number of active cores, and memory activity, can significantly skew energy consumption measurements if not accounted for. We show -- via empirical experiments, improved methodology, and careful examination of anomalies -- that when these factors are controlled for, notable discrepancies in prior work vanish. Our analysis suggests that the choice of programming language implementation has no significant impact on energy consumption beyond execution time.

arXiv.org
Show threaddemofoxOct 10, 2024
@ltratt @emeryberger it seems to suggest that program runtime is what decides energy usage. A counter example to this is games. Get your laptop or steam deck, whatever, and play 1 hour of hollow knight, then 1 hour of horizon forbidden west. Look at your battery level after each.
Then go watch a talk on mobile game dev talking about how to optimize for power usage to let the player play longer before they have to plug their phone in 😀
Show threaddemofoxOct 10, 2024
@ltratt @emeryberger not the main point, but it has a spherical cow feeling.
Show threademerybergerOct 10, 2024
@demofox @ltratt the paper doesn’t address GPUs but of course running something that is CPU/GPU intensive consumes a lot of energy and this is orthogonal to the point of the paper (which indeed only looks at CPU-intensive codes)
Show threaddemofoxOct 10, 2024
@emeryberger @ltratt not all the power talk is gpu related, but yeah... still great work, and games can be an edge case as a tiny percentage of applications, probably!
Show threadJosh SimmonsOct 10, 2024
@demofox @emeryberger @ltratt tbh I don't think games are going to be very different if you squint slightly. The only thing with the usual sussy CPU benchmarks is that they're large fixed blocks of work that happens once, games are doing a fixed amount of work at a target frequency. So if you do less work "in wall clock time" you can clock down harder and maintain the desired frequency. Since CPU benchmarks tend to saturate the machine you're just measuring the time modulated by the p-state
Show threadJosh SimmonsOct 10, 2024
@demofox @emeryberger @ltratt in general CPU benchmarks are more or less uniquely bad for measuring power usage, because computers are generally not running full blast constantly trying to churn numbers to generate a Mandelbrot fractal. Even games, which are hugely computationally expensive are generally not running your GPU or CPU at full blast constantly. (the older paper which tries to compare languages this way is just catastrophically flawed)
Show threadJosh Simmons
@demofox @emeryberger @ltratt or in other words, in a single core CPU benchmark the power usage is going to be dominated by time * power usage at max boost clock for single active core (on mobile / laptop add a modulo regarding how long you can sustain boost clocks before thermal throttling). Which is very simple and easy to model, but not very enlightening regarding the power profile of real world systems which tend to sit in lower power states most of the time.
Oct 10, 2024 at 2:57pmTusky
Show threademerybergerOct 10, 2024
@dotstdy @demofox @ltratt
Show threadJosh SimmonsOct 10, 2024
@emeryberger @demofox @ltratt Right, I appreciate that your paper is avoiding the issue, I'm just saying that it's vitally important for real world understanding of power use and how it relates to software, and especially in software like games where the wall clock runtime and their power use do not necessarily strongly correlate alone. (but I also think it's a relatively simple thing to account for in practice in napkin math terms)
Show threadJosh SimmonsOct 10, 2024
@emeryberger @demofox @ltratt btw on newer machines there's additional complexities too, which might not be easy to account for. (but also probably don't matter for the general ballpark here) e.g. you're controlling for the core c-states, which I think should also disable data-fabric c-states too, but there's also e.g. ddr memory power down, and I have no idea what can trigger / limit that. edit: Well hopefully the MSR estimations take care of accounting for that in terms of outcome anyway.