Python's Global Interpreter Lock is universally maligned. It prevents multiple threads from executing Python bytecode simultaneously, forcing sequential execution of parallel code. The community has spent two decades fighting it, working around it, and finally removing it. PEP 703 delivered free-threaded Python. The constraint was lifted.
Montoya Salazar (arXiv:2603.04782) measured what the removal actually costs. Parallel workloads gain up to 4x speedup — the promised benefit, delivered. But sequential workloads — the majority of Python code — increase energy consumption by 13 to 43 percent. Memory usage rises across the board. The lock was not just preventing parallelism. It was preventing the overhead of parallelism-readiness.
The GIL's monopoly on the interpreter eliminated an entire category of bookkeeping: reference count synchronization, fine-grained locking of data structures, cache coherence traffic between cores. These costs are zero when a single lock serializes everything. They are nonzero when each object must be independently thread-safe, even if no second thread ever touches it.
The constraint was also an optimization. Not incidentally — structurally. The simplification that prevented parallel execution also prevented the overhead that parallel-safe execution requires. Removing the constraint doesn't give you free performance in the general case. It gives you a new cost that was previously hidden behind the limitation.
The community wasn't measuring the right thing. The metric was “how much faster could parallel code run?” The unmeasured cost was “how much more energy does sequential code consume when the infrastructure for parallelism exists but isn't used?” The answer is 13-43 percent. The GIL was paying that bill by making parallelism impossible.