Pith. sign in

REVIEW 4 major objections 5 minor 59 references

An Empirical Study on the Performance and Energy Usage of Compiled Python Code

T0 review · 4 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read Compiling Python with Codon, PyPy, or Numba cuts single-threaded execution time and energy use by roughly 85–94 percent compared with the standard CPython interpreter, while Nuitka reliably reduces memory use.

desk verdict Solid, controlled comparison of eight Python compilers, but the abstract overstates PyPy/Numba improvements and the averaging is unclear; the core finding of large gains from Codon, PyPy, and Numba is credible. read the letter →

arxiv 2505.02346 v1 pith:ZXOS272O submitted 2025-05-05 cs.PL cs.PFcs.SE

Vincenzo Stoico , Andrei Calin Dragomir , Patricia Lago This is my paper · ORCID
classification cs.PLcs.PFcs.SE
keywords Pythoncompilationenergyefficiencyexecutiontimejust-in-timeahead-of-timeLast-LevelCachemissesbenchmarkingCPython
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 asks whether compiling Python code delivers the large efficiency gains that compiler projects advertise, and it answers with a controlled measurement on two testbeds. Eight compilers—PyPy, Numba, Nuitka, Mypyc, Codon, Cython, Pyston-lite, and the experimental Python 3.13 JIT—are each run on seven single-threaded, library-free benchmarks drawn from a standard language-benchmark suite, with CPU frequency fixed, Hyper-Threading disabled, all work pinned to one core, and 1,575 total executions compared against CPython. The central finding is that compilation can substantially cut both execution time and energy use: Codon improved server execution time by 94.18% and energy by 94.66%, PyPy by 86.67% and 86.89%, and Numba by 85.86% and 86.61%, while Nuitka consistently lowered memory usage on both testbeds. The study matters because it gives practitioners a measured, machine-controlled basis for choosing a Python compiler, and it shows that the choice of compiler, not just the choice of language, determines how much energy a Python workload consumes.

What carries the argument

The quantitative claims rest on simple ratios: percentage improvement is $(\bar{x}_{\mathrm{CPython}} - \bar{x}_{\mathrm{compiler}})/\bar{x}_{\mathrm{CPython}}$ and speedup is $\bar{x}_{\mathrm{CPython}}/\bar{x}_{\mathrm{compiler}}$, applied to execution time, energy, memory, and LLC miss percentages. Feeding those ratios is a full-factorial experiment: 9 execution modes (8 compilers plus CPython) × 7 benchmarks × 10–15 repetitions per treatment on each of two testbeds, with CPU frequency fixed, Hyper-Threading disabled, all commands pinned to one core, a two-minute warm-up and cooldown, and energy, memory, and cache measurements collected by hardware counters and OS timing. The machinery's job is to make the CPython-versus-compiler comparison clean enough that the large effect sizes can be attributed to compilation rather than to machine state, core count, or frequency scaling.

What would settle it

Run the same fixed-frequency, single-core protocol on a set of unmodified Python programs that use dictionaries, strings, file I/O, and popular numerical libraries, comparing CPython against Codon, PyPy, and Numba; if the average execution-time or energy improvements over CPython fall well below the 85–94% range, or reverse on several programs, the headline gains do not generalize beyond the benchmark set.

Watch

Extended reading notes

Core claim

The paper's central claim is that for single-threaded, library-free Python code of the kind found in standard language-benchmark suites, compiling the code instead of running it in CPython produces large, consistent improvements in execution time and energy consumption, and that the winning compilers are Codon, PyPy, and Numba. On the server, Codon's average execution-time improvement over CPython is 94.18% and its energy improvement is 94.66%; PyPy improves time by 86.67% and energy by 86.89%; Numba improves time by 85.86% and energy by 86.61%. Effect sizes are large (Cliff's $\Delta$ = 1.0) for these three against CPython, while the other five compilers show small or negligible effects on time and energy. The paper further claims that Nuitka reliably reduces memory usage on both testbeds, that no compiler reliably lowers the LLC miss rate, and that execution time and energy are strongly correlated in this setting, so the speedups translate almost directly into energy savings. It also reports a counterexample: on n_body, the AOT compilers Nuitka, Cython, and Mypyc make execution slower and more energy-hungry than CPython.

Load-bearing premise

The load-bearing premise is that the seven benchmark programs, after being adjusted for Numba's and Codon's typing and printing requirements, represent Python workloads closely enough that the measured 85–94% average gains carry over to real practitioner code.

Editorial extensions

If this is right

  • A developer with single-threaded, CPU-bound Python can expect Codon, PyPy, or Numba to cut execution time and energy by roughly 85–94% relative to CPython without changing the algorithm, provided the code is compatible with the compiler's type requirements.
  • Because the study finds a strong correlation between execution time and energy, speedups from compilation are also energy savings for fixed-frequency, single-core workloads.
  • Nuitka is the compiler to pick when memory footprint is the priority: it gives the lowest and least variable memory usage on both testbeds, though with high LLC miss rates and no large time or energy gains.
  • Compilation does not always help: n_body shows that some AOT compilers can regress both speed and energy on list-heavy numeric code, so compiler choice should be made per benchmark.
  • LLC miss rate is not a dependable indicator of compiler quality in this setting, since it varies by benchmark and testbed; most energy is consumed by uncore components such as the cache, which deserve separate study.

Reading between the lines

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

  • The 85–94% figures are likely an upper bound for general Python: the benchmark suite is numerical and library-free, conditions that favor static typing and tight loops, so I would expect smaller gains on I/O-heavy, library-heavy, or dynamically typed application code. The paper itself flags external validity as a limitation.
  • The strong time–energy correlation suggests that, under fixed frequency and single-core execution, energy use could be approximated from runtime alone, letting future studies skip dedicated energy hardware; this is an extension the paper does not make.
  • A targeted follow-up varying cache pressure (for instance, workloads that exceed cache size) would test whether Nuitka's combination of low memory and high LLC misses is a genuine memory-versus-cache trade-off with energy consequences, since uncore cache components dominate energy in this data.
  • Running the same harness on benchmarks that exercise dictionaries, strings, file I/O, and numerical library calls would map where each compiler's advantage fades; Numba's and Codon's known compatibility constraints suggest library-heavy code may not show the same gains.
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 / 5 minor

Summary. The paper reports a controlled empirical comparison of eight Python compilers (PyPy, Numba, Nuitka, Mypyc, Codon, Cython, Pyston-lite, and the experimental Python 3.13 JIT) against CPython on seven single-threaded, library-free benchmarks drawn from the Computer Language Benchmarks Game. The experiments were run on two testbeds (a server and an Intel NUC) with fixed CPU frequency and single-core execution, measuring energy consumption, execution time, memory usage, and LLC miss rate. The paper claims that compilation significantly improves execution time, energy, and memory usage, with Codon, PyPy, and Numba achieving very large speedups and energy savings, and that Nuitka consistently improves memory usage. It also reports that LLC miss behavior is inconsistent across benchmarks and compilers. A replication package is provided.

Significance. This is a useful and generally well-controlled empirical study. Its strengths include fixed CPU frequency, single-core execution with Hyper-Threading disabled, two distinct testbeds, randomized run order, warm-up and cool-down phases, 1575 total runs, a mix of JIT and AOT compilers, and a replication package. If the results are corrected and confirmed, the paper provides solid evidence that Codon, PyPy, and Numba deliver large and consistent execution-time and energy improvements for single-threaded numerical Python kernels, that Nuitka tends to reduce memory usage, and that LLC miss behavior is compiler- and benchmark-dependent. The study is not circular: it compares measured behavior against an external CPython baseline and does not fit models to its own conclusions. However, the headline quantitative claims and several internal statistics need reconciliation before the findings can be considered fully reliable.

major comments (4)
  1. [Abstract, Section 6.1, Section 6.2, Table 2] The abstract and Section 8 state that Codon, PyPy, and Numba achieve 'over 90% speed and energy improvements,' but Sections 6.1 and 6.2 report server averages of 86.89%/86.67% for PyPy and 86.61%/85.86% for Numba. Moreover, these Section 6 percentages cannot be reproduced from Table 2: using the server means in Table 2, the pooled improvement for PyPy is (24.98 - 2.36)/24.98 = 90.5% in time and (16.41 - 1.54)/16.41 = 90.6% in energy, not 86.67%/86.89%. The reported numbers appear to be unweighted means of per-benchmark improvement percentages, whereas the significance analysis in Section 5 pools all runs across benchmarks. The paper should define the aggregation rule, make the headline consistent with it, and restrict the 'over 90%' claim to Codon or qualify it.
  2. [Sections 5.2.2 and 6.3] The memory results are internally contradictory. Section 5.2.2 states that Cliff's Delta shows 'a small positive impact for both Nuitka and Codon' on the server, while Section 6.3 states that Nuitka's memory improvement is 'confirmed by Cliff's Delta test indicating a large effect size on the server' and that Codon 'also shows a large effect size on the server.' These cannot both be correct. Because the abstract's memory claim ('Nuitka optimizes memory usage consistently') rests on this analysis, the discrepancy must be resolved and the effect sizes reported consistently.
  3. [Sections 5.1, 5.2.1, 6.1, 6.2] The statistical analysis pools all runs across the seven benchmarks before applying Kruskal-Wallis and Cliff's Delta. Since the benchmarks differ by orders of magnitude in energy and execution time (Table 2), the reported Cliff's Delta of 1.0 reflects between-benchmark separation as much as within-benchmark compiler effects. A blocked or per-benchmark analysis (e.g., per-benchmark Cliff's Delta, or normalization per benchmark before pooling) is needed to support the 'large effect size' conclusion and to align with the per-benchmark percentages used in Section 6.
  4. [Section 4.1, Abstract, Section 8] The headline conclusions are stated more broadly than the experimental scope. Section 4.1 explains that the CLBG code was modified for Numba and Codon compatibility (class types, printing, @njit decorators), and Sections 7.2 and 7.3 acknowledge that code characteristics and the exclusion of third-party libraries and parallelism may favor these compilers. The abstract and Section 8 should scope the claims to single-threaded, library-free, compute-intensive Python kernels rather than presenting the improvements as general Python compilation benefits.
minor comments (5)
  1. [Section 6.4] The heading uses 'LCC miss percentage' instead of 'LLC miss percentage'.
  2. [Figure 2b] The caption mentions two shades for NUC versus server, but the figure does not define which shade is which; a legend or footnote should be added.
  3. [Section 6.1] The phrase 'increase energy consumption of 47.96%, -68.65%, -54.98%' mixes positive and negative signs without defining the sign convention; rephrase as 'change by +47.96%, -68.65%, -54.98%' or similar.
  4. [Table 1 and throughout] Compiler names are inconsistent (e.g., 'MyPyC' in Table 1 versus 'Mypyc' in the text and figures); standardize the naming.
  5. [Section 8] The conclusion's phrase 'over 90% improvement on the majority of benchmarks' should be accompanied by the appropriate per-benchmark figure or table reference so readers can verify it against Figure 3.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the study is a direct empirical measurement against external CLBG benchmarks and an independent CPython baseline.

full rationale

The paper's claims are derived from direct measurement of seven CLBG benchmarks executed with eight compilers plus CPython on two testbeds, using EnergiBridge, perf, and time. There is no fitted model, no parameter whose value is later relabeled as a prediction, and no quantity in the results is defined in terms of the quantity it is used to explain. The reported improvements are computed from observed execution times and energy readings relative to CPython, and the conclusions are comparisons to an independent baseline rather than consequences of any prior result by the same authors. The abstract's 'over 90%' wording is a summary of observed per-benchmark improvements and is discussed in Section 6; even if the aggregate percentages are internally inconsistent or not directly reproducible from Table 2, that is a reporting and aggregation concern, not circular reasoning. The Section 7 internal and external validity threats acknowledge that benchmarks were modified for Numba and Codon and that the selection may favor certain compilers, but acknowledging limitations does not make the measurements circular. The authors' self-citations (the replication package, Experiment Runner, and their earlier methodology article) support tooling and experimental procedure; they are not load-bearing evidence for the efficiency rankings, which rest on external measurement tools and an independent CPython comparison. Under the required standard of quoting a specific reduction of a derived claim to its own input, no circular step exists in this paper.

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

No fitted parameters or invented entities appear: the study is observational. The central claims rest on the representativeness of the chosen benchmarks, the correctness of the modified code, the validity of RAPL and perf measurements, and the effectiveness of the fixed-frequency, single-core experimental controls. Those are domain assumptions rather than free parameters.

assumptions (5)
  • domain assumption RAPL-based energy readings from EnergiBridge accurately capture the software energy consumption attributable to each run.
    Used throughout Section 4.2 and 5 as the energy measurement basis. RAPL is a hardware counter, but attributing package and DRAM energy to a single process assumes background activity and temperature effects are controlled.
  • domain assumption The seven CLBG benchmarks, after modification for Numba and Codon, remain representative of compute-intensive Python workloads.
    Section 3.2 and 4.1 rely on this for external validity. The benchmarks are small, single-threaded, and library-free, which may not generalize to typical Python code.
  • domain assumption Fixing CPU frequency and pinning execution to one core removes platform variability, so measured differences are attributable to the compiler.
    Section 3.2 and 4.1 state frequency and core count are fixed factors. This control is necessary for the internal validity of the comparison.
  • domain assumption The minimal code changes made for Numba and Codon do not materially alter the algorithms' performance characteristics.
    Section 4.1 and 7.1 describe type specifications and decorators. If these changes favor static typing or alter data flow, the comparison is biased.
  • domain assumption perf LLC miss percentage is a valid and stable measure of cache behavior for these workloads.
    Section 4.2 and 5.2.3 use perf as the LLC measurement tool. The paper notes high variability and inconsistent results, so the reliability of this assumption is uncertain.

how reviews work

0 comments
Cite this review

Pith. "Pith review of An Empirical Study on the Performance and Energy Usage of Compiled Python Code." pith.science (2026). https://pith.science/paper/ZXOS272O

@misc{pith2026250502346,
  author       = {Pith},
  title        = {Pith review of: An Empirical Study on the Performance and Energy Usage of Compiled Python Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZXOS272O}},
  note         = {Machine review of arXiv:2505.02346}
}
read the original abstract

Python is a popular programming language known for its ease of learning and extensive libraries. However, concerns about performance and energy consumption have led to the development of compilers to enhance Python code efficiency. Despite the proven benefits of existing compilers on the efficiency of Python code, there is limited analysis comparing their performance and energy efficiency, particularly considering code characteristics and factors like CPU frequency and core count. Our study investigates how compilation impacts the performance and energy consumption of Python code, using seven benchmarks compiled with eight different tools: PyPy, Numba, Nuitka, Mypyc, Codon, Cython, Pyston-lite, and the experimental Python 3.13 version, compared to CPython. The benchmarks are single-threaded and executed on an NUC and a server, measuring energy usage, execution time, memory usage, and Last-Level Cache (LLC) miss rates at a fixed frequency and on a single core. The results show that compilation can significantly enhance execution time, energy and memory usage, with Codon, PyPy, and Numba achieving over 90\% speed and energy improvements. Nuitka optimizes memory usage consistently on both testbeds. The impact of compilation on LLC miss rate is not clear since it varies considerably across benchmarks for each compiler. Our study is important for researchers and practitioners focused on improving Python code performance and energy efficiency. We outline future research directions, such as exploring caching effects on energy usage. Our findings help practitioners choose the best compiler based on their efficiency benefits and accessibility.

Figures

Figures reproduced from arXiv: 2505.02346 by the authors.

Figure 1
Figure 1. Experiment Execution [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Average energy usage, execution time, and memory usage for each benchmark by compiler. The dashed red line [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Speedup and Energy improvement on the server [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Memory usage improvement on the server across [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Correlation between execution time and Last-Level [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

59 extracted references · 54 canonical work pages

  1. [1]

    Sarah Abdulsalam, Donna Lakomski, Qijun Gu, Tongdan Jin, and Ziliang Zong

    work page

  2. [2]

    Joël Akeret, Lukas Gamper, Adam Amara, and Alexandre Refregier. 2015. HOPE: A Python just-in-time compiler for astrophysical computations. Astronomy and Computing 10 (2015), 1–8

    work page 2015

  3. [3]

    Pierre Augier, Carl Friedrich Bolz-Tereick, Serge Guelton, and Ashwin Vishnu Mohanan. 2021. Reducing the ecological impact of computing through education and Python compilers. Nature Astronomy 5, 4 (2021), 334–335

    work page 2021

  4. [4]

    Stefan Behnel, Robert Bradshaw, Craig Citro, Lisandro Dalcin, Dag Sverre Sel- jebotn, and Kurt Smith. 2010. Cython: The best of both worlds. Computing in Science & Engineering 13, 2 (2010), 31–39

    2010

  5. [5]

    Fernando Castor. 2024. Estimating the Energy Footprint of Software Systems: a Primer. arXiv preprint arXiv:2407.11611 (2024)

    arXiv 2024

  6. [6]

    Thomas D Cook and D T Campbell. 1979. Quasi-Experimentation: Design and Analysis Issues for Field Settings . Houghton Mifflin

    work page 1979

  7. [7]

    Elana Courtines, Georges Da Costa, and Patrica Stolf. 2021. Programming Lan- guage and Compiler Benchmarks. https://hal.science/hal-04610856v1/document. Accessed: 2025-01-1

    work page 2021

  8. [8]

    Luís Cruz. 2021. Green software engineering done right: a scientific guide to set up energy efficiency experiments. Blog post (2021)

    work page 2021

Show all 59 references
  1. [9]

    Ulrich Drepper. 2007. What every programmer should know about memory. Red Hat, Inc 11, 2007 (2007), 2007

    2007

  2. [10]

    Thomas Durieux. 2024. EnergiBridge Measurement Utility. https://github.com/ tdurieux/EnergiBridge

    2024

  3. [11]

    Jeff Forcier. 2024. Paramiko Python Package . https://github.com/paramiko/ paramiko

    2024

  4. [12]

    Python Software Foundation. 2025. PyPerformance: Python Performance Bench- mark Suite. https://github.com/python/pyperformance. Accessed: 2025-01-13

    2025

  5. [13]

    Stefanos Georgiou, Maria Kechagia, and Diomidis Spinellis. 2017. Analyzing programming languages’ energy consumption: An empirical study. InProceedings of the 21st Pan-Hellenic Conference on Informatics . 1–6

    2017

  6. [14]

    Isaac Gouy. [n. d.]. The Computer Language Benchmarks Game. https://benchmarksgame-team.pages.debian.net/benchmarksgame/. Ac- cessed: 2025-01-1

    2025

  7. [15]

    Brendan Gregg. 2019. BPF performance tools. Addison-Wesley Professional

    2019

  8. [16]

    Serge Guelton, Pierrick Brunet, Mehdi Amini, Adrien Merlini, Xavier Corbillon, and Alan Raynaud. 2015. Pythran: Enabling static optimization of scientific Python programs. Computational Science & Discovery 8, 1 (2015), 014001. https: //doi.org/10.1088/1749-4680/8/1/014001

    2015 doi

  9. [17]

    Shadi Ibrahim, Tien-Dat Phan, Alexandra Carpen-Amarie, Houssem-Eddine Chi- houb, Diana Moise, and Gabriel Antoniu. 2016. Governing energy consumption in Hadoop through CPU frequency scaling: An analysis. Future Generation Computer Systems 54 (2016), 219–232

    2016

  10. [18]

    IronPython Community. 2024. IronPython: An implementation of Python for the .NET Framework. https://ironpython.net/. Accessed: 2024-01-14

    2024

  11. [19]

    Chao Jin, Bronis R de Supinski, David Abramson, Heidi Poxon, Luiz DeRose, Minh Ngoc Dinh, Mark Endrei, and Elizabeth R Jessup. 2017. A survey on software methods to improve the energy efficiency of parallel computing.The International Journal of High Performance Computing Appl...

    2017

  12. [20]

    Josh Juneau, Jim Baker, Frank Wierzbicki, Leo Soto, and Victor Ng. 2010. The Definitive Guide to Jython: Python for the Java Platform . Apress

    2010

  13. [21]

    Lukas Koedijk and Ana Oprescu. 2022. Finding significant differences in the energy consumption when comparing programming languages and programs. In 2022 International Conference on ICT for Sustainability (ICT4S) . IEEE, 1–12

    2022

  14. [22]

    Siu Kwan Lam, Antoine Pitrou, and Stanley Seibert. 2015. Numba: A llvm-based python jit compiler. In Proceedings of the Second Workshop on the LLVM Compiler Infrastructure in HPC. 1–6

    2015

  15. [23]

    Ivano Malavolta, Vincenzo Stoico, and Patricia Lago. 2024. Ten Years of Teaching Empirical Software Engineering in the Context of Energy-Efficient Software. In Handbook on Teaching Empirical Software Engineering . Springer, 209–253

    2024

  16. [24]

    Olivier Melançon, Marc Feeley, and Manuel Serrano. 2023. An Executable Seman- tics for Faster Development of Optimizing Python Compilers. InProceedings of the 16th ACM SIGPLAN International Conference on Software Language Engineering . 15–28

    2023

  17. [25]

    Juan Julián Merelo-Guervós, Israel Blancas-Alvarez, Pedro A Castillo, Gustavo Romero, Pablo García-Sánchez, Victor M Rivas, Mario García-Valdez, Amaury Hernández-Águila, and Mario Román. 2016. Ranking the Performance of Com- piled and Interpreted Languages in Genetic Algorithm...

    2016

  18. [26]

    Ingo Molnár. 2024. Performance analysis tools for Linux . https://man7.org/linux/ man-pages/man1/perf.1.html

    2024

  19. [27]

    mypy developers. 2025. mypyc: Compile Python Modules to C Extensions . https: //github.com/mypyc/mypyc

    2025

  20. [28]

    Sebastian Nanz and Carlo A Furia. 2015. A comparative study of programming languages in rosetta code. In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Vol. 1. IEEE, 778–788

    2015

  21. [29]

    Nuitka Developers. 2024. Nuitka - The Python Compiler. https://nuitka.net/. [Accessed: 2024-03-05]

    2024

  22. [30]

    Oracle. 2024. GraalPy: A high-performance Python implementation for the JVM. https://www.graalvm.org/python/. Accessed: 2024-01-14

    2024

  23. [31]

    Replication package. 2025. Replication package for this study. https://github. com/S2-group/python-compilers-rep-pkg

    2025

  24. [32]

    Yun Peng, Ruida Hu, Ruoke Wang, Cuiyun Gao, Shuqing Li, and Michael R Lyu

  25. [33]

    Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, Jácome Cunha, João Paulo Fernandes, and João Saraiva. 2021. Ranking programming languages by energy efficiency. Science of Computer Programming 205 (2021), 102609

    2021

  26. [34]

    Rolf-Helge Pfeiffer. 2024. On the Energy Consumption of CPython. In Interna- tional Conference on the Quality of Information and Communications Technology . Springer, 194–209

    2024

  27. [35]

    Simon Portegies Zwart. 2020. The ecological impact of high-performance com- puting in astrophysics. Nature Astronomy 4, 9 (2020), 819–822

    2020

  28. [36]

    Banijamali Pouyeh. 2024. On the impact of Codon compilation on energy con- sumption and performance of Python code. (2024)

    2024

  29. [37]

    PyPy Developers. 2024. PyPy - Fast, flexible, and compliant Python interpreter. https://www.pypy.org/. [Accessed: 2024-03-05]

    2024

  30. [38]

    Pyston developers. 2025. Pyston-lite: Python JIT as an Extension Module . https: //github.com/pyston/pyston

    2025

  31. [39]

    Python Core Developers. 2024. Experimental JIT Compiler in Python 3.13. In Python 3.13 Release. Python Software Foundation. Experimental feature

    2024

  32. [40]

    Nurzihan Fatema Reya, Abtahi Ahmed, Tashfia Zaman, and Md Motaharul Islam

  33. [41]

    Omid Saedi. 2024. Towards Eco-Conscious Python: A Comparative Analysis of Performance, Energy Efficiency and Carbon Emissions Between CPython and Alternative Implementations. (2024)

    2024

  34. [42]

    Ariya Shajii, Ibrahim Numanagić, Riyadh Baghdadi, Bonnie Berger, and Saman Amarasinghe. 2019. Seq: a high-performance language for bioinformatics. Pro- ceedings of the ACM on programming languages 3, OOPSLA (2019), 1–29

    2019

  35. [43]

    Ariya Shajii, Gabriel Ramirez, Haris Smajlović, Jessica Ray, Bonnie Berger, Saman Amarasinghe, and Ibrahim Numanagić. 2023. Codon: A compiler for high- performance pythonic applications and dsls. In Proceedings of the 32nd ACM SIGPLAN International Conference on Compiler Const...

    2023

  36. [44]

    Software and Vrije Universiteit Amsterdam Sustainability Group. 2025. Experi- ment Runner. https://github.com/S2-group/experiment-runner

    2025

  37. [45]

    Stack Overflow. 2024. Stack Overflow Developer Survey 2024. https://survey. stackoverflow.co/2024/ Accessed: September 25, 2024

    2024

  38. [46]

    Rizwan Ali Tau Leng, Jenwei Hsieh, Victor Mashayekhi, and Reza Rooholamini

  39. [47]

    Mark Thom, Gerhard W Dueck, Kenneth Kent, and Daryl Maier. 2018. A survey of ahead-of-time technologies in dynamic language environments. In Proceedings of the 28th Annual International Conference on Computer Science and Software Engineering. 275–281

    2018

  40. [48]

    Anthony Tolley. 2022. Pyjion: A JIT compiler for CPython. https://github.com/ tonybaloney/pyjion. Accessed: 2024-01-14

    2022

  41. [49]

    Nicolas van Kempen, Hyuk-Je Kwon, Dung Tuan Nguyen, and Emery D Berger

  42. [50]

    Max Weber, Christian Kaltenecker, Florian Sattler, Sven Apel, and Norbert Sieg- mund. 2023. Twins or false friends? a study on energy consumption and perfor- mance of configurable software. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 2098–2110

    2023

  43. [51]

    Claes Wohlin, Per Runeson, Martin Höst, Magnus C Ohlsson, Björn Regnell, An- ders Wesslén, et al. [n. d.]. Experimentation in Software Engineering [electronic resource]: An Introduction. ([n. d.])

  44. [52]

    Qiang Zhang, Lei Xu, and Baowen Xu. 2022. RegCPython: A Register-based Python Interpreter for Better Performance. ACM Transactions on Architecture and Code Optimization 20, 1 (2022), 1–25

    2022

  45. [53]

    Qiang Zhang, Lei Xu, and Baowen Xu. 2024. Python meets JIT compilers: A simple implementation and a comparative evaluation. Software: Practice and Experience 54, 2 (2024), 225–256

    2024

  46. [54]

    arXiv preprint arXiv:2410.05460 (2024)

    It’s Not Easy Being Green: On the Energy Efficiency of Programming Languages. arXiv preprint arXiv:2410.05460 (2024)

    2024

  47. [59]

    Qiang Zhang, Lei Xu, Xiangyu Zhang, and Baowen Xu. 2022. Quantifying the interpretation overhead of Python. Science of Computer Programming 215 (2022), 102759

    2022

  48. [2002]

    Linux HPC Revolution 45 (2002)

    An empirical study of hyper-threading in high performance computing clusters. Linux HPC Revolution 45 (2002)

    2002

  49. [2014]

    In International Green Computing Conference

    Program energy efficiency: The impact of language, compiler and imple- mentation choices. In International Green Computing Conference . IEEE, 1–6

  50. [2023]

    Annals of Emerging Technologies in Computing (AETiC) 7, 3 (2023), 92–110

    GreenPy: evaluating application-level energy efficiency in Python for green computing. Annals of Emerging Technologies in Computing (AETiC) 7, 3 (2023), 92–110

    2023

  51. [2024]

    In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering

    Less is More? An Empirical Study on Configuration Issues in Python PyPI Ecosystem. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–12

Pith tools

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