No performance gain from threading on CPU-bound Python tasks

A CPython 3.x service uses the threading module to execute independent numerical kernels concurrently on a multi-core host, yet wall-clock time remains identical to a single-threaded baseline. The GIL serializes execution of Python bytecodes, so CPU-bound work does not achieve true parallelism with threads, while I/O-bound tasks benefit because the lock is released during blocking system calls. Switching to multiprocessing bypasses the GIL through separate interpreter processes, but introduces serialization and inter-process communication costs that may outweigh benefits for short-lived tasks.

The unresolved question is where the practical boundary lies between these two models for a given workload profile. Specifically:

• Is the complete absence of speedup in CPU-bound threading code solely a consequence of GIL serialization, or does voluntary thread preemption add measurable overhead even when lock contention is minimal?
• What quantitative threshold—task duration, payload size, or core count—makes multiprocessing overhead acceptable compared with the cumulative GIL-wait time of a threaded implementation?
• For applications that alternate between CPU-bound computation and blocking I/O, does combining threading for I/O waits with multiprocessing for compute introduce coordination hazards that neither model presents in isolation?