△Click " Python cat " above to follow, and reply " 1 " to receive the e-book
Flowering cat language: In the latest issue of Python Weekly ( click to read ), I shared the latest news about the GIL-free proposal (PEP-703), which has already detonated the technical community! Here is an article to share, the main content is the translation of the official announcement, you can explore the follow-up development plan:
Source: Heart of the Machine
The GIL in Python will no longer exist, which is a huge win in the realm of the AI ecosystem. PyTorch core maintainer Dmytro Dzhulgakov said with emotion.
What is the GIL? The full name of GIL is Global Interpreter Lock (global interpreter lock), which is not unique to Python, but a concept introduced when implementing CPython (Python interpreter).
We can understand GIL as a mutex, which is used to protect objects in Python and prevent multiple threads from executing Python bytecode at the same time, thereby ensuring thread safety.
Source: https://realpython.com/python-gil/
However, GIL has a disadvantage, that is, only one thread can execute on one CPU at a time, and multiple threads cannot be mapped to multiple CPUs, so that Python cannot achieve true multi-thread concurrency, thereby reducing execution efficiency .
Now, the Python team has officially accepted the proposal to remove the GIL and made it an optional mode , which is good for developers.
This contribution was made by a software engineer at Meta named Sam Gross, and it took him over four years to complete the project.
After hearing the news, everyone applauded. Yann LeCun, one of the three giants of deep learning, sent a message of congratulations: Without the GIL, Python code can now freely execute multi-threading.
"Finally no more GIL in Python!"
"This is a landmark decision that the coding community has eagerly awaited."
For the details, let's see below.
CPython core developer Thomas Wouters wrote an article describing the details of GIL-free in Python and looking forward to future developments.
Thanks a lot for everyone's feedback on the no-GIL proposal, the overall positive support. The Steering Committee intends to accept the no-GIL proposal and will share with you the specific details below.
Our basic assumptions are:
In the long term (roughly 5+ years), no-GIL builds should be the only builds;
We want to be very careful about backwards compatibility. We don't want another Python 3 situation where all 3rd party code changes needed to accommodate no-GIL builds should only apply to with-GIL builds (although backwards compatibility with older Python versions still needs to be addressed). This doesn't work with Python 4. We are still considering the requirements for ABI compatibility and other details of these two builds, and the impact on backwards compatibility;
We'd like to see community support before we commit to a full move to no-GIL. We can't just change the defaults, we want the community to figure out what they're doing to support us. Our core development team needs to gain experience with the new build mode and everything related. We need to sort out thread safety in existing code and need to figure out new C APIs and Python APIs. We also need to convey these insights to others in the Python community and ensure that the changes we want to make and the changes we want others to make are desirable;
At any point before our default no-GIL setting, we'd like to be able to change our minds if it proves to be too disruptive for too little benefit. This also means that we roll back all our work, so no-GIL-specific code should be somewhat identifiable until we decide to make no-GIL the default.
Currently, we see the road ahead in three phases:
In the short term, we will make no-GIL builds available as an experimental build mode, probably in 3.13 (and possibly 3.14). It's experimental because our core development team, while supporting this build mode, doesn't expect the entire community to support it. We need time to figure out what we want to do, at least in terms of API design and packaging and distribution, so that we can get support from the community. We also discourage distributors from releasing experimental no-GIL builds as the default interpreter.
In the medium term, after we are confident that we have enough community support to make production use of no-GIL feasible, we will support no-GIL builds, but not by default, but at a certain target date or in a certain Python version using It becomes the default way. The exact timing will depend on many factors, such as how compatible the API changes end up being, how much work the community thinks they still need to do, etc. We expect this to take at least one to two years. Once we announce support, expect some distributors to start shipping no-GIL by default.
Long term, we want no-GIL to be the default, and remove all traces of the GIL (but without unnecessarily breaking backwards compatibility). We don't want to wait too long, after all, the existence of two commonly used build modes at the same time will cause a great burden on the community (such as the need to double test resources and debug scenarios). But we can't be too hasty. We think this process will take five years.
Of course throughout the process, our entire development team will need to evaluate progress in real time and make adjustments to the timeline.
Reference link:
https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474
https://twitter.com/dzhulgakov/status/1685667015800066048
The Python cat technical exchange group is open! In the group, there are current employees of domestic first-tier and second-tier factories, as well as students studying in domestic and foreign colleges and universities. There are programming veterans with more than ten years of coding experience, and newcomers who have just started primary and secondary schools. The learning atmosphere is good! Students who want to join the group, please reply to the " communication group " in the official account to get Brother Mao's WeChat (decline the advertising party, if you are the one!)~
Not enough? try them
▲ Python Trend Weekly #2: Rust makes Python great again
▲ Python project engineering best practice guide
▲ Python program debugging analysis big killer collection
▲ 8 tips for speeding up Python optimization
▲ Python Trend Weekly #7: I hate using asyncio
If you found this article helpful
Please generously share and like , thank you !