How efficient is threading in Python?

CPython uses reference counting with a cyclic garbage collector for memory management. To make this practical, it has a mechanism called the "global interpreter lock" which protects the reference counting system, along with all the other interpreter internals.

On a single-core machine, this doesn't matter - all threading is faked via time-slicing, anyway. On a multiple core machine, it makes a difference: a CPU bound Python program running on CPython won't make use of all of the available cores.

There are a number of possible responses to this:

• use multiple processes instead of multiple threads (also opens up future scalability to multiple machines, rather than different cores within a single machine)
• use a Python implementation with a more multicore friendly garbage collection mechanism (such as Jython, IronPython or PyPy)
• move the more intensive CPU operations out to C code and release the GIL while doing the calculations (thus allowing the C code to run on other cores even though only a single Python thread is active at any one time)

If threads are being used to convert blocking IO to a non-blocking operation, then that works just fine in standard CPython without any special modifications - IO operations already release the GIL.

You overcome this by using multiprocessing instead! It's as simple as multithreading in python but gives you the full power of all your cpu cores.

multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.

One option is to use a different implementation of Python, like Jython or IronPython. That way, you still get the benefits of having the Python language without having to deal with the GIL. However, you wouldn't have the ability to use the CPython-only libraries.

Another option is to use different constructs than threads. For example, if you use Stackless Python, Tasklets are an alternative.

The threading is efficient in CPython, but threads can not run concurrently on different processors/cores. This is probably what was meant. It only affects you if you need to do shared memory concurrency.

Other Python implementations does not have this problem.

after finding solution (below) I wonder why python still has threading class

from multiprocessing import Pool def some_function(x): return x*x Xs = [i for i in xrange(1, 1000)] # make 1, 2, ..., 999, 1000 pool = Pool(processes=16) # start 16 worker processes on 16 CPU print pool.map(some_function, Xs) # print out