The Green Side of the Lua

The United Nations’ 2030 Agenda for Sustainable Development highlights the importance of energy-efficient software to reduce the global carbon footprint. Programming languages and execution models strongly influence software energy consumption, with interpreted languages generally being less efficient than compiled ones. Lua illustrates this trade-off: despite its popularity, it is less energy-efficient than greener and faster languages such as C. This paper presents an empirical study of Lua’s runtime performance and energy efficiency across 25 official interpreter versions and just-in-time (JIT) compilers. Using a comprehensive benchmark suite, we measure execution time and energy consumption to analyze Lua’s evolution, the impact of JIT compilation, and comparisons with other languages. Results show that all LuaJIT compilers significantly outperform standard Lua interpreters. The most efficient LuaJIT consumes about seven times less energy and runs seven times faster than the best Lua interpreter. Moreover, LuaJIT approaches C’s efficiency, using roughly six times more energy and running about eight times slower, demonstrating the substantial benefits of JIT compilation for improving both performance and energy efficiency in interpreted languages.

💡 Research Summary

The paper “The Green Side of the Lua” investigates how the execution model of the Lua programming language influences its runtime performance and energy consumption, a topic that aligns with the United Nations 2030 Agenda’s emphasis on green software. The authors selected a comprehensive set of Lua implementations: 17 official interpreter releases ranging from version 5.3.0 to 5.5.0, eight Just‑In‑Time (JIT) compilers (LuaJIT 2.0.0‑2.1.1 and the LuaJIT Remake), and a baseline C implementation taken from the Computer Language Benchmarks Game (CLBG).

Benchmarks were drawn from the CLBG suite and consist of seven computational kernels—binary‑trees, fannkuch‑redux, fasta, k‑nucleotide, mandelbrot, n‑body, and spectral‑norm—executed with “slow” inputs to guarantee sufficient workload. Each benchmark was run ten times under each interpreter/compiler, and the authors used Intel’s Running Average Power Limit (RAPL) interface to record energy consumption in two domains: CPU package and DRAM. To minimise thermal noise, the system was allowed to cool to a baseline temperature of 32.2 °C before each run, with a 5 % temperature variance permitted. Outliers were removed using the inter‑quartile range (IQR) method before statistical analysis.

The results show a clear monotonic improvement in energy usage across successive Lua interpreter releases, especially after the introduction of Lua 5.4.0, where package energy dropped from 422.85 J to 283.45 J and DRAM energy from 13.98 J to 9.31 J. More strikingly, all JIT‑based implementations dramatically outperform the interpreters. LuaJIT 2.0.4 achieves the lowest package energy (40.77 J) and DRAM energy (1.55 J), representing an 85 % and 83 % reduction respectively compared with the most efficient interpreter, Lua 5.4.7 (275.65 J package, 9.15 J DRAM). In terms of runtime, LuaJIT 2.0.4 averages 2.17 seconds per benchmark, whereas Lua 5.4.7 averages 15.16 seconds—a roughly seven‑fold speedup.

Correlation analysis reveals a near‑perfect positive relationship (≈ 0.99) among runtime, package energy, and DRAM energy across all versions, confirming that longer execution times directly translate into higher energy consumption. Benchmark‑level inspection identifies fannkuch‑redux and spectral‑norm as the most energy‑intensive kernels, yet even for these workloads LuaJIT delivers 6‑8× improvements over the interpreter.

When compared with the C baseline, LuaJIT still consumes about six times more energy and runs about eight times slower, while plain Lua is 38 times more energy‑hungry and 55 times slower than C. Thus, JIT compilation narrows the gap between a dynamic language and a compiled language dramatically, but does not eliminate it entirely.

The authors acknowledge several threats to validity: reliance on a single hardware platform (Intel i7‑8550U laptop), potential inaccuracies of RAPL as an indirect energy estimator, the limited set of benchmarks, and version‑specific internal optimisations that are not fully disclosed. Nevertheless, they mitigate these concerns through repeated measurements, thermal control, and transparent statistical treatment.

In conclusion, the study provides empirical evidence that JIT compilation is a powerful lever for improving both performance and energy efficiency of interpreted languages, thereby contributing to greener computing practices. The findings suggest that developers and organizations seeking to reduce carbon footprints should consider JIT‑enabled runtimes where possible. Future work could extend the methodology to other dynamic languages (e.g., Python, Ruby), explore multi‑core scaling, and evaluate a broader range of hardware (including ARM and GPU platforms) to assess the generality of the observed energy‑performance trade‑offs.