iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Python 3.13 does not remove the Global Interpreter Lock (GIL) from every CPython installation. It adds an optional, experimental free-threaded build that can let multiple Python threads execute in parallel across available CPU cores. That can help some CPU-bound threaded programs, but it is not a universal speed switch: single-threaded performance, extension compatibility, memory use, and thread-safety details all matter.
What changes when the GIL is disabled?
In conventional CPython, the GIL allows only one thread at a time to execute Python code. A free-threaded build can run Python code in multiple threads simultaneously, so a suitable CPU-bound program may use more than one core without relying on separate processes.
This is a change to the interpreter and its runtime behavior, not a setting that transforms a standard Python installation into a no-GIL interpreter. PEP 703 describes the changes needed to make the GIL optional, including adjustments to reference counting, memory management, container safety, and locking APIs. The proposal is at PEP 703.
Parallel execution creates an opportunity for speedup, not a guarantee. The result depends on the program’s work, how it divides that work among threads, available CPU cores, and whether its dependencies allow the GIL to remain disabled.
#1 Best Overall
Python 3.13 makes free-threading optional
The ordinary GIL-enabled build remains the default. Python 3.13 offers a separate free-threaded build, commonly identified by an executable such as python3.13t or python3.13t.exe. Official macOS and Windows installers optionally include free-threaded binaries; building CPython from source requires the --disable-gil configuration option. The Python 3.13 free-threading documentation describes the available builds and their status.
Python labels the feature experimental. Its documentation cautions that work is ongoing and that users should expect bugs and a substantial single-threaded performance hit. Treat a free-threaded build as an option to evaluate for a particular application, not a default upgrade recommendation.
How to verify the build and the running process
There are two different questions: does this interpreter support free-threading, and is the GIL disabled right now? Check both in the process whose behavior you care about:
import sys
import sysconfig
print("Free-threaded build:", sysconfig.get_config_var("Py_GIL_DISABLED"))
print("GIL enabled now:", sys._is_gil_enabled())sysconfig.get_config_var("Py_GIL_DISABLED")indicates whether the interpreter build supports free-threading.sys._is_gil_enabled()reports whether the GIL is currently enabled in that process.
A free-threading-capable build can still run with the GIL enabled. The documentation also says python -VV and sys.version identify a free-threading build, but those identify the build rather than establish the current runtime state.
Why the GIL might turn back on
A free-threaded build can enable the GIL at runtime using the PYTHON_GIL environment variable or the -X gil command-line option. In addition, importing a C API extension that is not marked as supporting the free-threaded mode may cause the interpreter to enable the GIL and print a warning. That is why checking only the executable name or build configuration is not enough.
Check every dependency that uses a C extension against its current project documentation and the exact interpreter build you run. Installation alone does not prove that an extension is compatible with the GIL disabled. Python 3.13’s “What’s New” documentation says pip 24.1 or newer is required to install packages with C extensions in the free-threaded build; that requirement does not certify that a particular package supports free-threading.
What the performance trade-off means
For Python 3.13, the official documentation reports about 40% overhead on the pyperformance suite in single-threaded execution compared with the default GIL-enabled build. This is a suite-level result, not a forecast for every application. The documentation attributes the largest impact to the specializing adaptive interpreter being disabled in the free-threaded build. Programs spending most of their time in C extensions or in I/O see less impact, according to the same documentation.
The documentation describes reducing overhead to 10% or less in a future release as an aim. That is a target, not a measured Python 3.13 result or a guarantee. For the release-specific figures and qualifications, see the Python 3.13 free-threading documentation.
To decide whether the build helps, compare the single-thread cost with measured speedup on your own multi-threaded workload and hardware. Also verify that the full dependency stack keeps the GIL disabled, and account for memory use and correctness. Benchmarking a different workload cannot establish how your application will perform.
Thread safety still requires deliberate design
Free-threaded CPython uses internal locks in built-in types such as dict, list, and set to protect against some concurrent modifications. That is not a broad promise that arbitrary shared-state operations will behave predictably. Python does not guarantee particular outcomes for concurrent modification; use synchronization such as threading.Lock when multiple threads need coordinated access to shared mutable state. See the Python 3.13 threading documentation.
Python 3.13 also documents several specific cautions:
- Sharing one iterator: using a single iterator object across threads is generally unsafe. Threads may see duplicate or missing elements, and the interpreter may crash.
- Accessing frames across threads: accessing a frame object from another thread may crash the program. The documentation says
sys._current_frames()is generally unsafe in a free-threaded build. - Memory use: some objects are immortalized to reduce reference-count contention. Applications that create many such objects may use more memory.
These are concrete limitations to account for, not evidence that every existing Python program will fail.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When is Python 3.13 free-threading worth testing?
It is most relevant when an application has CPU-bound work that can be divided among threads, and its dependencies support running with the GIL disabled. Test it with the actual workload and verify runtime state after imports. It is less compelling when a program is predominantly single-threaded, when its C extensions force the GIL back on, or when measured parallel gains do not outweigh the single-thread cost and added memory use.
For an initial evaluation, record performance in the default build, repeat the same workload in the free-threaded build on the same hardware, and check sys._is_gil_enabled() in the running process. Then test shared-state behavior and memory use under representative conditions before deciding whether to deploy it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →
