Methodology

All experiments ran on a laptop with Ubuntu 24.04.2 LTS (Linux 6.8.0-90-generic, x86-64) and an Intel Core i7-8550U CPU @ 1.80 GHz. Only the minimal necessary operating-system processes were active during measurements, and every execution started from a calibrated CPU temperature so that all programs share comparable starting conditions.

Energy was measured with Intel's Running Average Power Limit (RAPL) framework, reading the Model-Specific Registers to capture CPU Package and DRAM energy in Joules. Execution time was taken from the operating system's wall-clock mechanism, in seconds.

To keep the comparison fair across execution models, measurements cover strictly the runtime execution phase: for LuaAOT, the offline C code synthesis and gcc compilation are excluded. Every benchmark program was executed 10 times, and statistical anomalies were filtered with the Interquartile Range (IQR) method before aggregation.

The LuaAOT suite alone is not representative of everyday Lua code — its programs are written by language experts for maximum speed. It is therefore complemented with four suites built on widely used Lua libraries, covering data structures, higher-order functions, linear algebra and object orientation.

Thermal conditions were calibrated once by idling for 60 seconds and recording the resulting average CPU temperature as the baseline, T_baseline = 32.2 °C. Each subsequent execution only started once the current average core temperature satisfied T_start ≤ T_baseline + 5 °C. A larger tolerance would speed up data collection at the cost of thermal variability.

A battery endurance study complements the RAPL measurements: with display brightness at minimum, background synchronization disabled and wireless interfaces off, the number of continuous benchmark iterations was counted from a full charge to complete depletion.

Improvements are reported with the GPS-UP metrics, each computed against a baseline implementation:

To classify the impact of an optimization, the GPS-UP Software Energy Efficiency Quadrant Graph (Figure 1) divides results into eight categories. Categories 1–4 are the green outcomes, where the optimization saves energy; categories 5–8 are the red outcomes, where the optimized version consumes more energy than the baseline.

The full experimental pipeline involved executing 30 programs ten times across 26 Lua implementations, requiring 11 hours and 10 minutes of active execution time and consuming about 653 kJ of Package energy and 21 kJ of DRAM energy.

The total data-collection time, however, substantially exceeded 24 hours: the thermal regulation protocol enforced cooldown periods between runs until the CPU temperature dropped back below the 32.2 °C baseline threshold.