What is GIL
First need to clear is GILnot a Python features, it is a concept at the time of implementation of the Python parser (CPython) introduced. It is a C ++ like language (grammar) standard, but may be a different compiler into executable code. Well-known compilers such as GCC, INTEL C ++, Visual C ++ and so on. Python is the same, the same piece of code may be executed by different execution environments Python CPython, PyPy, Psyco like. Like JPython which there is no GIL. However, because CPython is the default under most environmental Python execution environment. So CPython is Python, there is the concept taken for granted in many people's GILattributed to the Python language deficiencies. So here must first be clear: GIL is not a Python features, Python can not rely on GIL
So CPython implementation of GIL what is it? GIL full nameGlobal Interpreter Lock.
Why GIL
Due to the physical limitations too, each CPU core in the game manufacturers frequency has been replaced by a multi-core. In order to more effectively utilize the performance of multi-core processors, there have been multi-threaded programming, but the attendant is inter-thread synchronization of data consistency and state difficult. Even within the CPU Cache is no exception , in order to effectively solve data between multiple caches synchronized manufacturers spend a lot of thought, but also inevitably bring some performance loss.
Python of course can not escape, in order to take advantage of multi-core, multi-threaded Python began to support. And resolve data integrity and state synchronization between multiple threads, namely data security, the easiest way nature is locked. After so with the GIL this super lock, and when more and more code library developers accepted this setting, they began to rely heavily on this feature (which is the default python internal objects are thread-safe and need not be implementation considerations when additional memory locking and synchronization).
Slowly This implementation is found to be inefficient and boring. But when we tried to split and remove the GIL, we found a lot of library code developers are already heavily dependent on GIL and very difficult to removed. How hard? Be analogies, such as MySQL "small project" In order to split Buffer Pool Mutex that the big lock into each small lock also spent more time and then to version 5.7 large period of nearly five years, from 5.5 to 5.6, and still It continues. The company behind MySQL support and product development team has fixed go so hard, so that they let alone Python core development community and a high degree of contributors team do?
So there is simply more of the GIL is historical. If pushed to again, multithreading problems are still to face, but at least will be more elegant than the current GIL this way.
GIL impact
From the above description and definition of the official point of view, GIL is undoubtedly a global exclusive lock. There is no doubt that there is a global lock will have no small impact the efficiency of multi-threaded. Even almost equal to Python is a single-threaded program .
Because GIL, python only a GIL, when you run the python, you should get this lock to perform, in the face of I / O When operation will release the lock. In Python2, if the program is purely computational, not the I / O operation, the interpreter every 100 operations on the release of the lock, so that other threads have the opportunity to perform (through sys.setcheckinterval this number can be adjusted) the same GIL will only have time to get a running thread, other threads are in a wait state 1 , if it is CPU intensive code (circulation, calculation, etc.), due to the large computational effort and multi-calculating soon reach 100, then trigger GIL in competition with the release of multiple threads back and forth switching losses resources, so when multi-threaded CPU-intensive code is encountered, faster than single-threaded multi-threaded. 2 , if the I \ O intensive code (document processing, the web crawler), multithreading is actually open concurrently (not parallel), IO operations will be IO wait, wait thread A, B is automatically switched to the thread, thus enhance the efficiency, much faster than single-threaded
In python3.x in, GIL does not use ticks count, instead using a timer (after the execution time threshold is reached, the current thread releases the GIL), so CPU-intensive programs more friendly , but still does not address the same time caused only GIL It can issue a thread of execution, so the efficiency is still unsatisfactory.
Multicore, multithreaded worse than single-core multi-threaded , multi-threaded Nucleation is a single reason, each release GIL, wake up that thread can acquire the GIL lock, can be seamlessly executed, but in multi-core, CPU0 released after GIL, on the other CPU thread will compete, but could immediately be GIL get CPU0, resulting in several other threads on the CPU will be awake waiting to be awakened after the switching time to be scheduled into the state, this will cause the thread thrashing (thrashing), resulting in lower efficiency
"Python next want to take full advantage of multi-core CPU, to use multi-process", because what is it?
The reason: each process has its own independent GIL, without disturbing each other, so that you can execute in parallel in the true sense, so in python, the efficiency is better than multi-process multi-thread (only for multi-core CPU terms).
to sum up
Python GIL is actually the product features and performance, the trade-offs, especially in the presence of its rationality, there are objective factors difficult to change. From this sub-analysis, we can do some of the following simple conclusion:
- Because there GIL, the only multi-thread under the IO-intensive scenes get better performance, but in CPU-intensive (compute-intensive) or under high concurrency scenarios, the use of multi-process efficiency will be faster.
- GIL will continue to exist for a longer period of time, but will continue to improve it.