Running Python without the GIL (3.14t builds)

A free-threaded build of CPython is a separate interpreter, installed as python3.14t beside the usual python3.14, in which the global interpreter lock can be switched off. Without the GIL, the threads of one process run Python code on several cores at the same moment, so CPU-bound work can speed up with threads instead of processes. Python 3.14 is the first release in which this build is officially supported rather than experimental (PEP 779), and it is still optional: the default build keeps its GIL. Three costs come with it. Single-threaded code runs a little slower. An extension module that has not declared support for running without the GIL turns it back on for the whole process. And code that relied on the GIL to make several steps happen together needs locks of its own, on either build.

Two builds of Python 3.14

The two builds share the language and the standard library, but not compiled extension modules: a package with C code needs a wheel built for the free-threaded build. PEP 703 marks such builds with the letter t in their ABI tag, which is where sys.abiflags and the t in python3.14t come from. What’s New in Python 3.14 puts the cost at roughly 5 to 10 percent on single-threaded code, and the free-threading guide, measured with the pyperformance suite, at about 1 percent on macOS on Apple silicon to 8 percent on x86-64 Linux.

Which build am I running?

This file reports both things that matter: how the interpreter was built, and whether the GIL is on at this moment. It runs in your browser too, where it describes the browser’s default build:

"""Which build of CPython runs this file, and is the GIL on right now?"""
import sys
import sysconfig

print("free-threaded build:", sysconfig.get_config_var("Py_GIL_DISABLED") == 1)
print("'free-threading build' in sys.version:", "free-threading build" in sys.version)
print("ABI flags:", repr(getattr(sys, "abiflags", "")))  # contains 't' on a free-threaded build (Linux, macOS)
print("GIL enabled right now:", sys._is_gil_enabled())
print("new threads inherit the caller's context:", bool(sys.flags.thread_inherit_context))
print("catch_warnings() uses a context variable:", bool(sys.flags.context_aware_warnings))

free-threaded build: False
'free-threading build' in sys.version: False
ABI flags: ''
GIL enabled right now: True
new threads inherit the caller's context: False
catch_warnings() uses a context variable: False

sysconfig.get_config_var("Py_GIL_DISABLED") == 1 is the check the free-threading guide recommends for decisions about the build, and "free-threading build" in sys.version says the same in words. sys._is_gil_enabled() answers a different question, whether the GIL is on right now, which on a free-threaded build can change while the program runs. The last two lines are defaults that the free-threaded build changes, explained further down.

To get the free-threaded build on Windows, run py install 3.14t with the Python install manager. On macOS, the python.org installer has a Free-threaded Python package under Customize, which adds python3.14t. On Linux, use a distribution package if yours has one, or build CPython from source with ./configure --disable-gil.

What the GIL costs threads, measured

The same CPU-bound work, 32 pieces of one loop, runs on eight threads and then on eight processes. Each piece measures its own CPU time, so the output can say how many cores each pool kept busy at once:

"""The same CPU-bound work on 8 threads and on 8 processes: the processes show how many cores the computer
could give, the threads how many the GIL allowed them to use."""
import sys
import sysconfig
import time
from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor

WORKERS = 8
PIECES = 32
SIZE = 1_200_000  # loop iterations per piece


def work(n):
    """A pure-Python loop; returns the CPU time it took, measured in the worker that ran it."""
    began = time.thread_time()
    total = 0
    for i in range(n):
        total += i * i % 7
    return time.thread_time() - began


def cores_busy(label, executor_class):
    with executor_class(max_workers=WORKERS) as pool:
        list(pool.map(work, [1] * WORKERS))  # start every worker before the clock starts
        began = time.perf_counter()
        cpu = sum(pool.map(work, [SIZE] * PIECES))
        wall = time.perf_counter() - began
    print(f"{label}: {cpu:.2f} s of CPU in {wall:.2f} s, cores busy at once: {cpu / wall:.1f}")
    return cpu / wall


if __name__ == "__main__":
    free = sysconfig.get_config_var("Py_GIL_DISABLED") == 1
    print(f"free-threaded build: {free}, GIL enabled: {sys._is_gil_enabled()}")
    threads = cores_busy("8 threads  ", ThreadPoolExecutor)
    processes = cores_busy("8 processes", ProcessPoolExecutor)
    if threads < 1.2:
        print("verdict: the threads stayed within one core; the processes show there were more to use")
    else:
        print("verdict: the threads ran Python code on several cores at once, as the processes did")

free-threaded build: False, GIL enabled: True
8 threads  : 2.50 s of CPU in 3.04 s, cores busy at once: 0.8
8 processes: 2.37 s of CPU in 1.05 s, cores busy at once: 2.3
verdict: the threads stayed within one core; the processes show there were more to use

Both pools did the same CPU work, about 2.4 seconds of it. The processes show how many cores the computer could give at that moment, here 2.3 on a computer busy with other programs, and finished in 1.05 seconds. The threads needed 3.04 seconds and kept 0.8 cores busy, below one, because with the GIL on only one of them runs Python code at a time, however many cores are idle. Run the same file with python3.14t and the threads’ figure rises to meet the processes’, since each thread then runs on a core of its own.

What changes for your code

Built-in types such as dict, list and set protect each of their own operations with internal locks, so one append() or one d[key] = value is as safe as with the GIL. Anything made of several steps is not: a check followed by an update, counter += 1, moving an item between two lists. Those already needed a lock on the default build, and without the GIL their races happen far more often. The free-threading guide also warns that sharing one iterator between threads is not safe, and that a frame’s local variables must not be read from another thread while it runs.

A few switches and habits decide how a program behaves on each build. PYTHON_GIL=1 or -X gil=1 turns the GIL on in a free-threaded build, and PYTHON_GIL=0 or -X gil=0 keeps it off. The flag thread_inherit_context gives each new thread a copy of its creator’s context. A start-up check tells a program whether its threads will run in parallel. And a lock around next() makes one iterator safe to share.

Check yourself

The GIL switches, their failure on the default build and the changed defaults, reproduced Pro: opens with a Pro, Premium or Ultimate pass

Code that is correct on both builds: iterators, locks and what they cost, measured Pro: opens with a Pro, Premium or Ultimate pass

Interview questions

Key takeaways

• The free-threaded build is a separate interpreter, python3.14t, officially supported from Python 3.14 and optional.
• Check the build with sysconfig.get_config_var("Py_GIL_DISABLED") and the running state with sys._is_gil_enabled().
• With the GIL on, CPU-bound threads keep at most one core busy; without it, they use several.
• An extension module without declared support turns the GIL back on; PYTHON_GIL and -X gil override it.
• Built-in types protect single operations; anything made of several steps still needs your own lock.