Pith. sign in

REVIEW 4 major objections 6 minor 18 references

Green AI: Which Programming Language Consumes the Most?

T0 review · 4 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A controlled experiment measuring five languages across seven AI algorithms finds that programming language choice can change energy consumption by up to 54x, with compiled languages consistently ahead.

desk verdict A useful and honest measurement campaign whose headline language ranking overstates what the design can identify, because each language is a single library and the aggregate totals are driven by a few algorithm implementations. read the letter →

arxiv 2501.14776 v1 pith:QODTJANK submitted 2024-12-31 cs.CY cs.AIcs.PL

Niccolò Marini , Leonardo Pampaloni , Filippo Di Martino , Roberto Verdecchia , Enrico Vicario This is my paper · ORCID
classification cs.CYcs.AIcs.PL
keywords energyconsumptionprogramminglanguagesgreenAImachinelearningempiricalsoftwareengineeringtrainingandinferencemeasurementalgorithmimplementation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that the choice of programming language is a first-order factor in how much energy an AI workload consumes. In a controlled experiment covering five languages, seven classic machine-learning algorithms, and three tabular datasets, the authors measure training and inference energy separately. They find that compiled and semi-compiled languages (C++ and Java) consistently consume less than interpreted languages (Python, R, MATLAB), with up to a 37x spread in training and a 54x spread in inference. A sympathetic reader should care because this suggests concrete levers for making AI greener without abandoning familiar tools.

What carries the argument

The carrying mechanism is a controlled factorial experiment rather than a single mathematical identity. For each combination of five programming languages, seven off-the-shelf machine-learning libraries/algorithms, and three datasets, the authors run 30 repetitions, measure total hardware energy with an OS-level power-monitoring library, take the median, and sum over datasets; training and inference are isolated at the line-of-code level, and startup and compilation overhead are excluded. The rankings and the 37x and 54x ratios emerge from these cumulative medians.

What would settle it

Choose one algorithm, implement it in two different mainstream libraries within the same language, and re-run the same measurement protocol; if the within-language spread is as large as the 54x between-language spread, the language-level ranking collapses to an implementation-level result.

Watch

Extended reading notes

Core claim

The paper's central claim is that programming languages have a considerable, measurable impact on AI energy consumption. Measured in joules on a single machine, cumulative training energy ranks C++ < Java < MATLAB < Python < R, with R consuming 37 times C++; cumulative inference energy ranks Java < C++ < Python < R < MATLAB, with MATLAB consuming 54 times Java. The rankings are not stable across phases or across algorithms, and no algorithm is intrinsically the most expensive in every language. The paper also argues, as a conjecture based on the per-algorithm breakdown, that the specific implementation of an algorithm may matter more than the language or the algorithm family itself.

Load-bearing premise

The load-bearing premise is that a single off-the-shelf library per language stands in for that language; if the choice of library, not the language, drives the energy difference, the headline ranking does not isolate language as a cause.

Editorial extensions

If this is right

  • If the claim holds, developers can reduce AI energy use by favoring compiled or semi-compiled languages (C++ or Java) for deployment, especially for inference-heavy services.
  • If the claim holds, energy-efficiency rankings for AI should be reported separately for training and inference, since the order flips between phases.
  • If the claim holds, optimizing a single hot algorithm implementation in an interpreted language may yield bigger energy savings than switching languages.
  • If the claim holds, existing practices do not need to be upended: the trade-off between energy efficiency and development ease can be managed by keeping current languages and choosing efficient implementations.
  • If the claim holds, the energy cost of an AI algorithm is not intrinsic to the algorithm family, so Green AI benchmarks should report language and library context.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because each language is represented by one library, the 54x figure should not be quoted as a property of the languages alone; a same-language comparison across multiple libraries would isolate how much of the gap is implementation.
  • A testable consequence not pursued in the paper is that energy-efficient libraries written in compiled languages could be wrapped in Python to retain developer ergonomics while recovering much of the efficiency gap.
  • The per-algorithm variance suggests that energy-aware tooling could profile the specific library version in use, rather than relying on a language-level lookup table.
  • If the implementation-dominates conjecture is right, energy rankings of languages will drift as libraries update, so the result is a snapshot tied to particular library versions.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. This paper reports a controlled empirical benchmark of the energy consumption of seven classical machine-learning algorithms (KNN, SVC, AdaBoost, decision tree, logistic regression, naive Bayes, random forest) as implemented in five languages (C++ via mlpack with AdaBoost from XGBoost, Java via WEKA with naive Bayes from OpenCV, Python via scikit-learn, MATLAB via the Statistics and Machine Learning Toolbox, and R via caret), across three UCI datasets (Iris, Breast Cancer, Wine Quality), for the training and inference phases. Each configuration is run 30 times on an Apple M2 and measured with CodeCarbon; medians are reported and totals are aggregated across datasets and algorithms. The authors report cumulative rankings (training: C++ < Java < MATLAB < Python < R, with R 37x above C++; inference: Java < C++ < Python < R < MATLAB, with a 54x maximum gap) and note that no language keeps its rank across phases. They further observe that single algorithm cells dominate language totals (e.g., R's logistic regression is 71.1% of R's training energy) and conjecture, as their most important finding, that algorithm implementation, rather than language per se, may be the dominant factor. The design, however, uses exactly one library per language, so the 'language' factor is confounded with the library and its implementation; the authors acknowledge this in Section V-C.

Significance. If the central claims could be supported, the paper would be a useful contribution to Green AI: it would quantify the spread among off-the-shelf AI implementations, show that the training-versus-inference phase changes the efficiency ordering, and provide an empirically grounded warning against holistic 'language X is most efficient' claims. The study has real strengths: a systematic design with 30 repetitions in a controlled environment, direct energy measurement through a kernel-level tool, per-algorithm and per-phase results in Table I, a replication package, and an honestly flagged construct-validity threat (Section V-C), with the headline insight explicitly labeled a conjecture (Section IV). The weaknesses are equally clear: the language effect is not identifiable with one library per language, the cumulative rankings are driven by a few outlier cells, no variance or inferential statistics accompany the medians, and some abstract/conclusion statements ('consistently consume less') are contradicted by the paper's own Table I.

major comments (4)
  1. [§II-D, §V-C] The focal independent variable 'programming language' is confounded with the single library chosen to represent it: Python is represented only by scikit-learn, C++ only by mlpack (AdaBoost from XGBoost), Java only by WEKA (naive Bayes from OpenCV), R only by caret, and MATLAB only by its Statistics and Machine Learning Toolbox. Any measured difference therefore conflates the language with the implementation's algorithmic defaults, numerical routines, and optimization effort. The paper's own Section V-C states that a more correct scoping would be to understand which algorithm implementation choices in different programming languages are more energy efficient, which concedes the point. Yet the abstract and the answers to RQ1, RQ1.1, and RQ1.2 in Sections III and IV are phrased as causal language effects ('C++ is far more efficient than Java'; 'programming languages have a considerable impact on AI energy consumption'). The central claim of the paper is not identifiable from this design as stated. Please reframe the research question and headline claims to the level of the benchmarked language/library combinations, or include a second library per language for at least a few algorithms so the language effect can be separated from the implementation effect.
  2. [§III-A, Table I] The cumulative language rankings are not robust to the choice of aggregation. In the training phase, Java is the most efficient implementation in 4 of 7 algorithms (KNN, SVC, decision tree, naive Bayes) while C++ leads in only 3, yet C++ is declared the overall winner because the cumulative sums are dominated by single outlier cells: R logistic regression contributes 71.1% of R's training total, Python SVC contributes 63.4%, and Java random forest contributes 52.5%. A majority-of-algorithms vote would invert the C++/Java ordering, so statements such as 'C++ is far more efficient than Java' are an artifact of the particular basket of algorithms. The paper should either present per-algorithm paired comparisons (languages compared within each algorithm and dataset) as the primary analysis, or add robustness checks such as per-algorithm ratios, jackknifing over algorithms, or median-of-ratios aggregation, before drawing any language-level ranking.
  3. [§II-E, §V-A] Despite 30 repetitions per configuration, no measure of dispersion or inferential statistic appears anywhere in the paper; only medians and cumulative sums are reported. This is inconsistent with the contribution list's 'statistical and discursive interpretation' and with the claim in Section V-A that the 30-run design makes the study statistically resilient to random confounding factors. The headline contrasts (e.g., C++ vs Java in training, the 54x inference gap) should be accompanied by at least interquartile ranges or confidence intervals, and preferably a paired test over the 30 runs or a bootstrap for the ratio statements. Note also that Section V-A is headed 'Conclusion Validity' but its text addresses internal validity (history, maturation, instrumentation), so the classification of threats needs correction as well.
  4. [Abstract, §VII] The abstract and the conclusions state that compiled and semi-compiled languages (C++, Java) consistently consume less than interpreted languages (Python, MATLAB, R). This is contradicted by Table I for the training phase: for KNN, C++ (2.67 x 10^7 J) consumes more than both Python (1.61) and R (0.65); for decision tree, C++ (12.21) consumes more than Python (10.57); for AdaBoost, Java (32.76) consumes more than R (5.27). The 'consistently' claim holds only for the cumulative totals, where it is driven by the outlier cells discussed above. Please replace 'consistently' with a statement that is true of the data, e.g., that the smallest cumulative totals in both phases are attained by C++ and Java.
minor comments (6)
  1. [§III-A] The passage 'one could assume that linear regression is per se a very computational-intensive algorithm' appears to refer to logistic regression, and the accompanying claim that logistic regression consistently ranks second or third in training efficiency is not supported by Table I, where its training rank ranges from 3rd (C++) to 7th (R); please correct both the terminology and the rank statement.
  2. [Abstract, §II-B, Table I] Spelling: 'naive bayses' should be 'naive Bayes', and §II-B opens with 'we consider tree different datasets' instead of 'three different datasets'.
  3. [§III-B] The sentence 'Java consumes approximately two times less than the the second most energy efficient programming language (C++)' contains a duplicated 'the'.
  4. [§II-B] The dataset feature counts appear inconsistent with the UCI descriptions cited: Breast Cancer Wisconsin (Original) has 9 features (30 features belong to the diagnostic variant), and Wine Quality has 11 features rather than four; please verify the exact files used in the experiment, correct the text, and state the file versions in the replication package.
  5. [§V-A] The subsection is headed 'Conclusion Validity' but opens with 'In terms of internal validity' and mixes conclusion-validity and internal-validity threats; separate the categories under their correct headings.
  6. [References] Reference [8] is listed as 'B. Pereira and et al.', which is inconsistent with the author list of [6] for the same body of work; complete the citation or merge it with [6].

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's energy measurements are direct empirical observations, with no fitted parameters, no equation-level derivations, and no load-bearing self-citations.

full rationale

The paper's central claim—that programming languages have a considerable impact on AI energy consumption—is supported by direct measurements of energy consumption across five languages, seven algorithms, three datasets, and two AI phases. There is no derivation chain in which an output is constructed from its own inputs: no equations are fitted to data and then re-predicted, no parameter is calibrated on a subset and then reported as a finding on that same subset, and no uniqueness theorem or prior result is invoked to force the interpretation. The self-citations that appear (e.g., the authors' own systematic review of Green AI and their paper on threats to validity) serve as background and methodological framing, not as load-bearing evidence for the empirical ranking. The main skeptical concern—that each language is represented by a single library and that aggregate rankings are influenced by individual algorithm implementations—is a construct-validity threat, not a circularity. The paper explicitly acknowledges this in Section V-C, stating that a more correct scoping would be 'which algorithm implementation choices in different programming languages are more energy efficient,' and it labels the implementation-dominance interpretation as a conjecture in Section IV. These are honest limitations and interpretive caveats, not hidden reductions of the findings to their inputs. Therefore, no circular step can be exhibited, and the appropriate score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claim rests on measurement trust and representativeness assumptions rather than fitted parameters. The main non-standard assumptions are that CodeCarbon tracks true hardware energy on Apple Silicon, that one library per language represents the language, and that default hyperparameters are comparable across libraries.

assumptions (4)
  • domain assumption CodeCarbon on macOS accurately measures the hardware energy consumed by the executed algorithm code.
    All energy values in Table I and Figures 2-3 are treated as ground truth; measurement trust is stated in Section II-D.
  • domain assumption Popular off-the-shelf library implementations represent the programming language in AI practice.
    A single library per language is used (scikit-learn, mlpack, WEKA, caret, etc.), which conflates language and implementation; acknowledged as a construct validity threat in Section V-C.
  • domain assumption The median of 30 repetitions is a stable estimator that removes runtime confounding effects.
    The paper relies on medians without reporting variance or confidence intervals (Section II-E, Section III).
  • domain assumption Default hyperparameters, with variables set equal across libraries, make the seven algorithm implementations comparable.
    Section II-D states default settings are used; whether defaults are truly equivalent across libraries is not demonstrated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Green AI: Which Programming Language Consumes the Most?." pith.science (2026). https://pith.science/paper/QODTJANK

@misc{pith2026250114776,
  author       = {Pith},
  title        = {Pith review of: Green AI: Which Programming Language Consumes the Most?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QODTJANK}},
  note         = {Machine review of arXiv:2501.14776}
}
read the original abstract

AI is demanding an evergrowing portion of environmental resources. Despite their potential impact on AI environmental sustainability, the role that programming languages play in AI (in)efficiency is to date still unknown. With this study, we aim to understand the impact that programming languages can have on AI environmental sustainability. To achieve our goal, we conduct a controlled empirical experiment by considering five programming languages (C++, Java, Python, MATLAB, and R), seven AI algorithms (KNN, SVC, AdaBoost, decision tree, logistic regression, naive bayses, and random forest), three popular datasets, and the training and inference phases. The collected results show that programming languages have a considerable impact on AI environmental sustainability. Compiled and semi-compiled languages (C++, Java) consistently consume less than interpreted languages (Python, MATLAB, R), which require up to 54x more energy. Some languages are cumulatively more efficient in training, while others in inference. Which programming language consumes the most highly depends on the algorithm considered. Ultimately, algorithm implementation might be the most determining factor in Green AI, regardless of the language used. As conclusion, while making AI more environmentally sustainable is paramount, a trade-off between energy efficiency and implementation ease should always be considered. Green AI can be achieved without the need of completely disrupting the development practices and technologies currently in place.

Figures

Figures reproduced from arXiv: 2501.14776 by the authors.

Figure 1
Figure 1. Example of energy time series used for results quality [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Energy Consumption by Language and Algorithm (Training Phase) [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Energy Consumption by Language and Algorithm (Inference Phase) [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages

  1. [1]

    Energy and policy consid- erations for deep learning in nlp,

    E. Strubell, A. Ganesh, and A. McCallum, “Energy and policy consid- erations for deep learning in nlp,” 6 2019

    work page 2019

  2. [2]

    Quantifying the carbon emissions of machine learning,

    A. Lacoste, A. Luccioni, V . Schmidt, and T. Dandres, “Quantifying the carbon emissions of machine learning,” 10 2019

    work page 2019

  3. [3]

    On the dangers of stochastic parrots: Can language models be too big?,

    E. M. Bender, T. Gebru, A. McMillan-Major, and S. Shmitchell, “On the dangers of stochastic parrots: Can language models be too big?,” pp. 610–623, Association for Computing Machinery, Inc, 3 2021

    work page 2021

  4. [4]

    Green AI,

    R. Schwartz, J. Dodge, N. A. Smith, and O. Etzioni, “Green AI,” Communications of the ACM , vol. 63, pp. 54–63, 11 2020

    work page 2020

  5. [5]

    A systematic review of Green AI,

    R. Verdecchia, J. Sallou, and L. Cruz, “A systematic review of Green AI,” Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery, vol. 13, no. 4, p. e1507, 2023

    work page 2023

  6. [6]

    Ranking programming languages by energy efficiency,

    R. Pereira, M. Couto, F. Ribeiro, R. Rua, J. Cunha, J. P. Fernandes, and J. Saraiva, “Ranking programming languages by energy efficiency,” Science of Computer Programming , vol. 205, p. 102609, 2021

    work page 2021

  7. [7]

    Analyzing programming languages’ energy consumption: An empirical study,

    S. Georgiou, M. Kechagia, and D. Spinellis, “Analyzing programming languages’ energy consumption: An empirical study,” in Proceedings of the 21st Pan-Hellenic Conference on Informatics , pp. 1–6, 2017

    work page 2017

  8. [8]

    A Gravitational Theory of the Quantum

    B. Pereira and et al., “Energy efficiency across programming lan- guages: How do energy, time, and memory relate?,” arXiv preprint arXiv:1709.00329, 2017

    work page Pith review arXiv 2017

Show all 18 references
  1. [9]

    The goal question metric approach,

    V . Basili, G. Caldiera, and H. D. Rombach, “The goal question metric approach,” Encyclopedia of software engineering , pp. 528–532, 1994

    1994

  2. [10]

    Wohlin, P

    C. Wohlin, P. Runeson, M. H ¨ost, M. C. Ohlsson, B. Regnell, and A. Wessl´en, Experimentation in software engineering . Springer Science & Business Media, 2012

    2012

  3. [11]

    Threats to validity in software engineering–hypocritical paper section or essential analysis?,

    P. Lago, P. Runeson, Q. Song, and R. Verdecchia, “Threats to validity in software engineering–hypocritical paper section or essential analysis?,” in 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM’24, pp. 314–324, Association for C...

    2024

  4. [12]

    Green AI: Do Deep Learning Frameworks Have Different Costs?,

    S. Georgiou, M. Kechagia, T. Sharma, F. Sarro, and Y . Zou, “Green AI: Do Deep Learning Frameworks Have Different Costs?,” in 2022 IEEE/ACM 44st International Conference on Software Engineering (ICSE), 2022

    2022

  5. [13]

    Analyzing programming languages’ energy consumption: An empirical study,

    S. Georgiou, M. Kechagia, and D. Spinellis, “Analyzing programming languages’ energy consumption: An empirical study,” in Proceedings of the 21st Pan-Hellenic Conference on Informatics , PCI ’17, (New York, NY , USA), Association for Computing Machinery, 2017

    2017

  6. [14]

    Programming languages ranking based on energy measurements,

    A. Gordillo, C. Calero, M. Moraga, F. Garc ´ıa, J. P. Fernandes, R. Abreu, and J. Saraiva, “Programming languages ranking based on energy measurements,” Software Quality Journal , vol. 32, pp. 451–470, 2024

    2024

  7. [15]

    Impact of programming languages on energy consumption for sorting algorithms,

    T. B. Chandra, P. Verma, and A. K. Dwivedi, “Impact of programming languages on energy consumption for sorting algorithms,” in Software Engineering: Proceedings of CSI 2015 , pp. 93–101, Springer, 2019

    2015

  8. [16]

    Energy-efficient programming lan- guages for mobile applications,

    S. Mahadevappa and S. Figueira, “Energy-efficient programming lan- guages for mobile applications,” in 2021 IEEE Global Humanitarian Technology Conference (GHTC), pp. 33–38, 2021

    2021

  9. [17]

    Understanding the impact of object oriented programming and design patterns on energy efficiency,

    S. Maleki, C. Fu, A. Banotra, and Z. Zong, “Understanding the impact of object oriented programming and design patterns on energy efficiency,” in 2017 Eighth International Green and Sustainable Computing Confer- ence (IGSC), pp. 1–6, IEEE, 2017

    2017

  10. [18]

    Quantifying electric vehicle mileage in the United States,

    L. Zhao, E. R. Ottinger, A. H. C. Yip, and J. P. Helveston, “Quantifying electric vehicle mileage in the United States,” Joule, vol. 7, no. 11, pp. 2537–2551, 2023

    2023

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.