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 threadjorendorffOct 10, 2024

@ltratt @emeryberger Great paper.

Interesting that last-level cache misses increase power usage, since not a lot of work is getting done in that case — the CPU must be stalled most of the time. I guess the chip can't power anything down while waiting for memory.

Figure 11(a) has me confused. The relationship has to be (and appears to be) linear in the limit as x increases, even if something else is going on near x=0. I'm curious:

  • Why are there so many different x-values? I would have expected shootout programs to have either 1 core or all N cores in use at all times, with very few exceptions.
  • Is this an artifact of averaging somehow?
  • Do all PC multiprocessors have this curve?
  • If this is real, surely the explanation is already known to the manufacturer. Is there a way to ask?
Show threademeryberger
@jorendorff @ltratt The # of active cores (x values) depends on the degree of parallelism in the application implementations - it's not all sequential or perfect parallelism divided among all available cores, but rather lies somewhere in between.
Oct 10, 2024 at 8:46pmWeb