Python 3.12 vs 3.14 vs 3.14t: GIL and free-threading benchmark

Generated 2026-09-12T12:41:05 on Apple M5 (10 cores), macOS-26.6.2-arm64-arm-64bit. 160 measurements, median of 10 repeats.

3 columns, one interpreter. 3.14 (GIL on), 3.14t (free-threaded) and 3.14t (PYTHON_GIL=0 forced) are the same binary run with different GIL settings - not different builds. No stock (GIL-enabled) build of that version was measured here, so a gap between any of them and 3.12 mixes the version change with the free-threaded build's own overhead.

Key findings

• CPU-bound cpu_primes at 8 threads vs 1 - 3.12: 0.9x, 3.14 (GIL on): 0.9x, 3.14t (free-threaded): 3.9x.
• CPU-bound cpu_float at 8 threads vs 1 - 3.12: 0.9x, 3.14 (GIL on): 1.0x, 3.14t (free-threaded): 4.1x.
• Single-threaded overhead of the free-threaded build (1 worker, median over CPU/contended workloads): +12% vs 3.12, +0% vs the same binary with the GIL on.
• I/O-bound io_sleep is unaffected: all builds overlap waits equally (8-thread times within 1% of each other).
• Contended contended_list_append at 8 threads: free-threaded 0.284 s vs 3.12 0.108 s (slower by 164%).
• Contended contended_dict_update at 8 threads: free-threaded 0.847 s vs 3.12 0.356 s (slower by 138%).
• Threads on 3.14t vs processes on 3.12 for the same prime-counting work at 8 workers: 0.054 s vs 0.155 s - multiprocessing pays start-up and pickling costs.
• Measurement noise: 10 timed repeats per cell, median coefficient of variation 2.1%; 19 of 160 cells exceed 10% (marked ~ in the tables).
• Library 'duckdb' does NOT support free-threading: importing it re-enabled the GIL (_duckdb), so its '3.14t (free-threaded)' results are effectively GIL-on.
• Library numpy_small_ops at 8 threads vs 1 - 3.12: 1.0x, 3.14 (GIL on): 1.0x, 3.14t (free-threaded): 4.2x.
• Library numpy_matmul at 8 threads vs 1 - 3.12: 1.8x, 3.14 (GIL on): 1.8x, 3.14t (free-threaded): 1.7x.
• Library pandas_groupby at 8 threads vs 1 - 3.12: 4.7x, 3.14 (GIL on): 4.5x, 3.14t (free-threaded): 4.8x.
• Library duckdb_query at 8 threads vs 1 - 3.12: 6.1x, 3.14 (GIL on): 5.6x, 3.14t (free-threaded): 5.0x, 3.14t (PYTHON_GIL=0 forced): 5.3x.
• Library sklearn_fit at 8 threads vs 1 - 3.12: 5.4x, 3.14 (GIL on): 5.3x, 3.14t (free-threaded): 6.2x.
• Library fastapi_sync_cpu at 8 threads vs 1 - 3.12: 1.0x, 3.14 (GIL on): 1.0x, 3.14t (free-threaded): 3.9x.
• Library fastapi_async_json at 8 threads vs 1 - 3.12: 1.9x, 3.14 (GIL on): 1.6x, 3.14t (free-threaded): 2.0x.

Summary

Interpreter configurations

Speed-up at a glance

Cells: speed-up from 1 to 8 workers, and wall time at 8 workers. ⚠ = the free-threaded run actually had the GIL re-enabled by an extension module (hover, focus or tap any symbol for its meaning).

Bare Python workloads (stdlib only)

Library workloads (optional tier)

Third-party extension modules. Some release the GIL in C already (so they scale on every build), some hold it, and some re-enable it for the whole process on import.

Free-threading support check (check_gil_support.py, probed on 3.14t)

Implementation differences: what actually changed inside CPython

All statements below about this machine are measured (see the facts table); the rest describes CPython's design as documented in PEP 703 (free-threaded CPython), PEP 779 (free-threading officially supported in 3.14), PEP 683 (immortal objects) and the CPython free-threading HOWTOs.

1. Timeline

• 3.12 - one GIL per interpreter (PEP 684 made it per-subinterpreter for the C-API). Threads never run bytecode concurrently.
• 3.13 - PEP 703 lands as an experimental separate build (--disable-gil, binary python3.13t). Specialisation was switched off in that build, costing ~40% single-thread performance.
• 3.14 - PEP 779: the free-threaded build is officially supported (no longer experimental). The specialising interpreter is back on, single-thread overhead is quoted by the core team at roughly 5-10%, and the build is what this report calls 3.14t. The default (non-t) 3.14 build is unchanged and still has the GIL.

2. Reference counting: biased, deferred, immortal

With the GIL, Py_INCREF is a plain non-atomic increment. Without it, every increment from every thread would have to be atomic - a large slowdown. Free-threaded CPython uses three tricks:

• Biased reference counting - each object records its owning thread (ob_tid) and keeps two counters: ob_ref_local, touched only by the owner without atomics, and ob_ref_shared, an atomic counter used by every other thread. The true count is their sum; they are merged when the object is freed or its ownership changes.
• Immortal objects (PEP 683) - None, True, small ints, interned strings, static types etc. have a saturated count and are never inc/dec'd, so hot shared constants create no cache-line traffic.
• Deferred reference counting - functions, code objects, modules and top-level classes are referenced from the interpreter's evaluation stack without counting; the garbage collector accounts for those references instead. 3.14 goes further with tagged stack references in the evaluation loop.

The price is a bigger object header: ob_tid, a one-byte ob_mutex, GC bits and the two counters. Measured here: sys.getsizeof(object()) is 16 bytes on 3.12 and 32 on 3.14t; a small int and a short str each grow by 16 bytes.

3. Memory allocator and garbage collector

• mimalloc replaces pymalloc. It has per-thread heaps, so allocation needs no global lock, and its heap structures let the collector enumerate objects.
• Because of that, the free-threaded build drops the 16-byte PyGC_Head doubly-linked-list pre-header that every GC-tracked object carries on 3.12. Measured here: [], {} and class instances come out the same size on both builds - for them the bigger object header is exactly offset by the missing GC header. It does not cancel everywhere: in the same table a 2-tuple and a lambda are still 8 bytes larger on 3.14t.
• The cycle collector is stop-the-world: it pauses every thread at a safe point (the "eval breaker" check), runs a single-generation collection, then resumes them. The default (GIL) 3.14 build keeps its generational collector. Note that gc.get_threshold() reads (2000, 10, 10) on every 3.14 column versus (700, 10, 10) on 3.12. That is a 3.12→3.14 change rather than a free-threading one - but this run cannot be the evidence for it, because it never measured a stock 3.14: all three 3.14 columns are the one free-threaded binary.

4. Per-object locks and critical sections

The GIL used to make list.append, dict.__setitem__ and friends safe by accident. The free-threaded build makes them safe on purpose: each object has a one-byte lock (ob_mutex) and C code wraps mutating operations in critical sections (Py_BEGIN_CRITICAL_SECTION). Critical sections are automatically suspended when a thread blocks (e.g. on another lock), which avoids lock-ordering deadlocks. Most reads of lists and dicts are lock-free, protected by quiescent-state-based reclamation (QSBR) so memory is never freed under a reader.

What this guarantees is memory safety of the interpreter, not atomicity of your program: d[k] += 1 is still a read-modify-write race, exactly as it was with the GIL - only the interleavings become more frequent. That is why contended_dict_update above uses an explicit threading.Lock, and why contended_list_append shows the cost of taking the list's lock on every call.

5. The interpreter loop

• The specialising adaptive interpreter rewrites bytecodes in place, which is a data race if two threads run the same code object. 3.14t solves this with thread-local bytecode (-X tlbc, PYTHON_TLBC): each thread specialises its own copy. This is what brought single-thread overhead down from the ~40% reported for 3.13t. The "single-threaded overhead" finding above does not isolate it: its figure against 3.12 also carries every other 3.12→3.14 change, and its figure against "3.14 (GIL on)" compares the free-threaded binary with itself.
• The experimental JIT is not built for the free-threaded build. sys._jit.is_available() is False on the binary measured here - though that call only reports whether this binary was compiled with the JIT, so it confirms the build rather than isolating free-threading as the reason.
• Thread switching no longer exists as a concept. sys.setswitchinterval still exists and still accepts a value, but with the GIL off there is no hand-off for it to govern - threads simply run.

6. Runtime knobs and semantics visible from Python

• sysconfig.get_config_var("Py_GIL_DISABLED") - is this a free-threaded build?
• sys._is_gil_enabled() - is the GIL on right now? (It can be re-enabled at runtime, see §7.)
• PYTHON_GIL=0|1 / -X gil=0|1 and sys.flags.gil - override the build default. This report's "3.14 (GIL on)" column is the free-threaded binary run with PYTHON_GIL=1: same allocator, same headers, same locks - only the GIL is re-added. It isolates the GIL's effect but is not identical to a stock 3.14 build.
• On the free-threaded build new threads inherit the caller's context variables by default (sys.flags.thread_inherit_context = 1) and warnings.catch_warnings becomes context-aware (sys.flags.context_aware_warnings = 1), because module-global mutable state is no longer protected by the GIL.
• concurrent.futures.ThreadPoolExecutor and plain threading.Thread are unchanged; they simply scale now. asyncio is still single-threaded per loop, and multiprocessing still works.

7. C extensions and packaging

• Extension modules must opt in by declaring Py_mod_gil = Py_MOD_GIL_NOT_USED (multi-phase init) or calling PyUnstable_Module_SetGIL(m, Py_MOD_GIL_NOT_USED). If a module does not, CPython re-enables the GIL for the whole process and emits a RuntimeWarning. That is precisely what check_gil_support.py detects, and what happened with duckdb in this run.
• Wheels are tagged with the t ABI (cp314-cp314t-..., SOABI=cpython-314t-darwin); they are not interchangeable with cp314 wheels. The stable ABI (abi3) does not cover free-threaded builds in 3.13/3.14, so every extension needs a dedicated build.
• A pure-Python wheel (py3-none-any) runs on the free-threaded build automatically, but "runs" is not "thread-safe": the library still has to protect its own global state.
• Extensions that already released the GIL around long C loops (numpy's BLAS calls, DuckDB's query engine, scikit-learn's Cython nogil blocks) scaled across threads before free-threading; the gain from 3.14t is for code that holds the GIL - Python-level dispatch, small-array ops, per-element Python callbacks such as DataFrame.apply, and ordinary Python code. Which side an operation falls on is not a property of the library it lives in: numpy_small_ops and numpy_matmul above are the same library on opposite sides, and pandas_groupby scales on every build.

8. Measured facts (every configuration on this machine)

Methodology & how to reproduce

• Each (configuration, workload) pair runs in a fresh subprocess so an import that re-enables the GIL cannot leak into other measurements. Each thread count is timed 10x (--repeats, default 5); the median is plotted, error bars show the min-max range, and tables give median ± sample standard deviation. Cells whose coefficient of variation exceeds 10% are marked ~; treat differences smaller than the error bars as noise.
• Every workload returns a checksum that tests/ pins across thread counts, so splitting the work differently cannot change how much of it there is: exactly for the integer checksums, and to six decimal places for cpu_float, where float addition is not associative. One deliberate exception: io_sleep gives each thread a fixed number of waits, so its total work grows with the thread count - a flat line there means the waits overlapped, and its 1.0x "speed-up" is the good outcome, not the absence of one.
• BLAS/OpenMP are pinned to one thread (OPENBLAS_NUM_THREADS=1 etc.) so scaling reflects Python threads only. Every workload gets one untimed warm-up call first (cold caches, lazy imports, uvicorn start-up).
• Thread counts: 1, 2, 4, 8 on a 10-core Apple M5 (macOS-26.6.2-arm64-arm-64bit).

./setup.sh                                  # uv installs 3.12 + 3.14t, creates .venv312 / .venv314t
.venv312/bin/python -m bench.run            # bare-Python workloads (default)
.venv312/bin/python -m bench.run --libs     # + numpy / pandas / duckdb / scikit-learn / fastapi
.venv312/bin/python -m bench.compare_lib numpy   # one library: support check -> warn -> bench -> report
.venv312/bin/python -m bench.report         # regenerate results/report.html
.venv314t/bin/python check_gil_support.py numpy duckdb   # does a package support free-threading?

Appendix: interpreter GIL warnings captured during the run

<frozen importlib._bootstrap>:491: RuntimeWarning: The global interpreter lock (GIL) has been enabled to load module '_duckdb', which has not declared that it can run safely without the GIL. To override this behavior and keep the GIL disabled (at your own risk), run with PYTHON_GIL=0 or -Xgil=0.