Unlocking Python's Cores: Hardware Usage and Energy Implications of Removing the GIL

TL;DR

Disabling Python's GIL in an experimental build improves performance and reduces energy use for parallelizable workloads, but increases memory consumption and may worsen efficiency for sequential or lock-contention workloads.

Contribution

This study provides empirical measurements of energy, hardware utilization, and performance impacts of removing the GIL in Python 3.14.2 across various workload types.

Findings

Parallel workloads benefit from GIL removal with up to 4x faster execution.

Energy consumption correlates with execution time, not power draw, when GIL is disabled.

Memory usage increases due to thread-safety mechanisms and new memory allocators.

Abstract

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.