Free-Threaded Python (No-GIL) in 3.14: What It Means, Tested

The Global Interpreter Lock is a single mutex that lets only one thread execute Python bytecode at a time. It makes the interpreter simpler and single-threaded code fast, but it means that for CPU-bound work, adding threads buys you nothing — they just take turns holding the lock. Here's a benchmark that makes it concrete: run a heavy numeric loop as 4 serial tasks, then as 4 threads.

import sys, time
from threading import Thread

def cpu_work(n):
    x = 0
    for i in range(n):
        x += i * i
    return x

N, THREADS = 15_000_000, 4

# serial: THREADS tasks back to back
t0 = time.perf_counter()
for _ in range(THREADS):
    cpu_work(N)
serial = time.perf_counter() - t0

# threaded: one task per OS thread
t0 = time.perf_counter()
ts = [Thread(target=cpu_work, args=(N,)) for _ in range(THREADS)]
for t in ts: t.start()
for t in ts: t.join()
parallel = time.perf_counter() - t0

print(f"gil_enabled={sys._is_gil_enabled()}")
print(f"serial:   {serial:.2f}s")
print(f"threaded: {parallel:.2f}s  ->  {serial/parallel:.2f}x")

On the normal Python 3.14 build, threading it changes nothing — the real output:

gil_enabled=True
serial:   3.50s
threaded: 3.58s  ->  0.98x

0.98x. Four threads, four cores, and it's *very slightly slower* than doing the tasks one after another (that's thread overhead with no parallelism to pay for it). This is the GIL in one number, and it's why CPU-bound Python has always reached for multiprocessing instead.

Now the identical script, run on the free-threaded build — no code changes, just a different interpreter:

gil_enabled=False
serial:   3.86s
threaded: 0.99s  ->  3.91x

This is the whole promise of PEP 779: pure-Python parallelism without spawning processes, pickling data between them, or reaching for multiprocessing. For CPU-bound workloads that share a lot of in-memory state, that's a genuinely new capability in CPython.

The free-threaded interpreter is a separate binary, python3.14t, installed alongside the normal python3.14. You opt in:

# Option 1 - python.org installer: tick "free-threaded binaries"
#            (installs python3.14t next to python3.14)

# Option 2 - uv:
uv python install 3.14t

# It really is a different interpreter:
python3.14t -c "import sys; print(sys._is_gil_enabled())"   # False

To check what any interpreter is at runtime, two calls tell you everything:

import sys, sysconfig
print(sys._is_gil_enabled())                        # True (normal) / False (free-threaded)
print(sysconfig.get_config_var("Py_GIL_DISABLED"))  # 0 (normal) / 1 (free-threaded)

A free-threaded build can also re-enable the GIL at startup — useful when a C extension isn't ready — via a flag or an environment variable (both tested):

python3.14t -X gil=1 -c "import sys; print(sys._is_gil_enabled())"    # True
PYTHON_GIL=1 python3.14t -c "import sys; print(sys._is_gil_enabled())"  # True

Free-threading is opt-in for good reasons — you pay for the parallelism:

1. ~10% slower single-threaded. In my run the serial baseline went from 3.50s (GIL) to 3.86s (free-threaded) — about 10% overhead from per-object locking and biased reference counting. If your workload is single-threaded, you'd only lose.
2. More memory. The machinery that replaces the single lock adds per-object bookkeeping; expect a noticeably larger footprint.
3. C extensions must be rebuilt. Native extensions need a free-threaded (ABI) wheel — the big ones (NumPy, etc.) now ship them, but the long tail of packages may not, and an unprepared extension is why you'd re-enable the GIL.
4. Your own code needs to be thread-safe. The GIL accidentally protected a lot of sloppy shared-state code. Real parallelism means real data races if you share mutable state without locks.

Should you switch? Reach for the free-threaded build when you have CPU-bound work that parallelises and shares in-memory state — that's where the 3.91x lives, and where multiprocessing was previously your only option. Stay on the standard build for single-threaded apps, I/O-bound work (where asyncio/threads were already fine), or anything depending on C extensions that haven't shipped free-threaded wheels yet. It's supported now, but the ecosystem is still catching up — test before you ship.