Search papers, labs, and topics across Lattice.
This paper investigates the hardware utilization and energy consumption implications of disabling Python's Global Interpreter Lock (GIL) in Python 3.14.2 across four workload categories. The study reveals that while parallelizable workloads can achieve up to 4x speedup and proportional energy reduction with the free-threaded build, sequential workloads and those with high lock contention exhibit increased energy consumption and performance degradation. Energy consumption is shown to be proportional to execution time, while memory usage generally increases in the no-GIL build due to per-object locking and thread-safety mechanisms.
Freeing Python from the GIL can slash execution time and energy use for parallel workloads, but beware: sequential tasks might see a surprising energy *increase*.
Python's Global Interpreter Lock prevents execution on more than one CPU core at the same time, even when multiple threads are used. However, starting with Python 3.13 an experimental build allows disabling the GIL. While prior work has examined speedup implications of this disabling, the effects on energy consumption and hardware utilization have received less attention. This study measures execution time, CPU utilization, memory usage, and energy consumption using four workload categories: NumPy-based, sequential kernels, threaded numerical workloads, and threaded object workloads, comparing GIL and free-threaded builds of Python 3.14.2. The results highlight a trade-off. For parallelizable workloads operating on independent data, the free-threaded build reduces execution time by up to 4 times, with a proportional reduction in energy consumption, and effective multi-core utilization, at the cost of an increase in memory usage. In contrast, sequential workloads do not benefit from removing the GIL and instead show a 13-43% increase in energy consumption. Similarly, workloads where threads frequently access and modify the same objects show reduced improvements or even degradation due to lock contention. Across all workloads, energy consumption is proportional to execution time, indicating that disabling the GIL does not significantly affect power consumption, even when CPU utilization increases. When it comes to memory, the no-GIL build shows a general increase, more visible in virtual memory than in physical memory. This increase is primarily attributed to per-object locking, additional thread-safety mechanisms in the runtime, and the adoption of a new memory allocator. These findings suggest that Python's no-GIL build is not a universal improvement. Developers should evaluate whether their workload can effectively benefit from parallel execution before adoption.
