executing Python bytecode simultaneously. • Ensures only one native thread executes Python bytecode at a time within a single process. • Simplified CPython's memory management and C extension API.
for CPU-bound tasks. • I/O-bound tasks less affected as GIL is released during I/O operations. • Historically, multiprocessing was the primary way to achieve parallelism in Python for CPU-bound tasks, but with inter-process communication overhead.
Optional • PEP 703 proposes making the Global Interpreter Lock optional in CPython. • Introduces "free-threaded build" of Python where the GIL is disabled. • Aims to unlock true parallel execution for Python threads, especially for CPU-bound workloads.
an optional (or possibly default-disabled) feature in future releases. • Backward Compatibility: Many C extensions are written assuming the GIL will exist. • Performance Overhead: Free-threaded builds may run single-threaded code slower.
status for free-threaded Python From Python 3.14’s release notes: “The free-threaded build of Python is now supported and no longer experimental. This is the start of phase II where free-threaded Python is officially supported but still optional.”
3.14 was on October 2024 • Stable 3.14 release scheduled on 7 October 2025 • The performance penalty on single-threaded code in free-threaded mode is now roughly 5-10%.
lines of code in CPython and includes mimalloc, which is also approximately 15,000 lines of code. “ - PEP 703 We will compare the execution time of free-threaded interpreter vs GIL enabled default interpreter of Python 3.14.
3.5 s io_bound_single_thread 4.8 s 4.8 s io_bound_multi_thread 1.9 s 1.9 s cpu_bound_single_thread 2.7 s 3.1 s cpu_bound_multi_thread 2.7 s 0.8 s Flask_app_io_bound (multi thread) 31 req/20 s 32 req/20 s Flask_app_cpu_bound (multi thread) 47 req/20 s 90 req/20 s Benchmark results
+ Threading • Great for scenarios where parallelisation is needed - but multiprocessing is too complex / not suitable Note: Benchmarks here were done with a pre-release Python (3.14 RC2). 3.13 also shows similar results. • Always benchmark using your own workload before making a switch. • Watch out for library compatibility issues/bugs.
is released with support for a --disable-gil build time flag. There are two ABIs for CPython, one with the GIL and one without. Extension authors target both ABIs. 2. After 2–3 releases, (i.e., in 2026–2027), CPython is released with the GIL controlled by a runtime environment variable or flag. The GIL is enabled by default. There is only a single ABI. 3. After another 2–3 release (i.e., 2028–2030), CPython switches to the GIL being disabled by default. The GIL can still be enabled at runtime via an environment variable or command line flag. We are here now: PEP 779 Acceptance: “The free-threaded build of Python is now supported and no longer experimental. This is the start of phase II where free-threaded Python is officially supported but still optional.”
in the PEP will increase execution overhead for --disable-gil builds compared to Python builds with the GIL. • In other words, it will have slower single-threaded performance. • There are some possible optimizations to reduce execution overhead, especially for --disable-gil builds that only use a single thread. These may be worthwhile if a longer term goal is to have a single build mode, but the choice of optimizations and their trade-offs remain an open issue. In future, performance penalties will be reduced for free threaded interpreter.
new concurrency mode is unlocked for CPU bound programs without overhead of inter-process communication. - For single-threaded programs - Go with GIL-Disabled default interpreter - For programs using multiprocessing - Go with GIL-Disabled default interpreter
SiteGround - Reliable hosting with speed, security, and support you can count on.
adarshd
syumai
simotin13
masuda220
yusukebe
javiergs
rollbear
har1101
contour_gara
yaotti
mayuki
manfredsteyer
nrslib
aleyda
lara
62gerente
jdejongh
hannesfritz
ipullrank
watany
geshan
jcasabona
mojombo
skipperchong
