How Much FASTER Is Python 3.13 Without the GIL?

Python 3.13 introduces an experimental feature allowing the Global Interpreter Lock (GIL) to be optional, marking a significant shift for the language. The GIL, a mutex in CPython, has historically limited Python's multi-threading capabilities by allowing only one thread to execute bytecode at a time. Removing the GIL promises substantial performance boosts for multi-threaded applications but comes with complexities, such as potential breaks in existing packages that depend on it. While the transition to a no-GIL default may take years, its eventual adoption could enhance Python's parallel processing abilities, benefiting fields like AI and data science.

• The Global Interpreter Lock (GIL) has historically limited Python's performance by allowing only one thread to execute Python bytecode at a time.
• Python 3.13 introduces the option to make the GIL optional, an experimental feature that requires manual intervention to implement.

"The global interpreter log has been holding python back for years that's about to change with python 3.30 but there are dangers that you need to be aware of."

• The GIL has been a performance bottleneck for Python, but upcoming changes in Python 3.13 aim to address this issue.

• The GIL was introduced in Python 1.5 to protect Python object access by ensuring that only one thread executes Python bytecode at a time.
• It acts as a mutex in CPython, the default Python interpreter, which is an open-source project.

"The aim of the global interpreter lock or the Gill is to protect python object access by letting only one thread at a time execute python bite code."

• The GIL's primary purpose is to maintain thread safety in Python by serializing access to Python objects.

• The GIL is implemented in CPython, and its source code can be examined and modified.
• The commit that added the option to disable the GIL involves changes to multiple C files, including ceval_gil.c.

"So this is what that looks like so of course this is all written in C and the interesting thing is that you can also see the actual commit that added the option to disable the Gill."

• The implementation of the GIL is deeply integrated into CPython's source code, with specific commits dedicated to enabling or disabling it.

• While CPython has the GIL, other Python interpreters like Jython do not.
• The GIL ensures thread safety in Python's memory management but limits the effective use of multiple CPU cores in multi-threaded programs, impacting performance.

"Now though cpython the default python interpreter has the Gill currently in Python 3.12 there are interpreters like jython that don't the Gill ensures threat safety in Python's memory management."

• The GIL restricts multi-threaded performance but simplifies memory management and thread safety in Python.

• In the early days of Python, multi-threaded programs were less common, and single-threaded performance was the primary concern.
• The GIL was introduced to improve execution time of single-threaded code and simplify garbage collection and reference counting.

"In the early days multi-threaded programs were less common than they are now and single threaded performance was the main concern locking The Interpreter was a mechanism to improve the execution time of single threaded code."

• The GIL was a design choice made to optimize single-threaded performance and ease the development of concurrent code in Python.

• Removing the GIL in Python 3.13 can lead to significant performance boosts in multi-threaded applications, but it comes with challenges and potential risks.

"I'll show you some examples where it's going to give you a massive performance boost however it comes at a price."

• While the removal of the GIL can enhance performance, it requires careful consideration of the associated complexities and trade-offs.

• The GIL has been a critical component of Python's memory management and concurrency model, but evolving computational needs necessitate its re-evaluation.
• Python 3.13's experimental feature to disable the GIL marks a significant shift, promising performance improvements while posing new challenges for developers.

"It's a big change for python but what does it actually mean will it have any effect on you."

• The changes to the GIL in Python 3.13 represent a major evolution in Python's development, with potential impacts on performance and concurrency in Python applications.

• Concurrency involves designing and writing code that can execute multiple tasks simultaneously.
• Challenges include race conditions and memory corruption.
• Discussing concurrency issues with other developers can be beneficial.

"Of the protection against race conditions and memory corruption however designing and writing concurrent code is not always easy and can get you stuck to mitigate this try discussing with other developers like in my Discord channel the link is in the description."

• Writing concurrent code is complex and can lead to issues; collaboration and discussion can help mitigate these problems.

• A script is created to count the number of primes using different methods: single-threaded, multi-threaded, and multi-processing.
• Functions include checking for prime numbers, counting primes, and their threaded and multi-processing versions.
• The script prints Python version and checks if the Global Interpreter Lock (GIL) is disabled.
• Timing information is added to compare the performance of different methods.

"Let's take a look at an example I've created a basic example to test a few things related to processing and threading so this is a script that counts the number of prime so there is a function that checks whether there's a prime there is a count primes function and then there's a threaded version of that and we also have a multiprocessing version of that."

• The script demonstrates different methods of counting primes to evaluate the performance of concurrency techniques.

• The script uses Python 3.12, which does not have the option to disable the GIL.
• The performance of functions is tested with the GIL enabled.

"Currently on this particular system I'm using python 3.12 which doesn't have the option to disable the GIL so let's see what the performance of these functions is."

• Python 3.12 is used for testing, and the GIL cannot be disabled in this version.

• Regular Python command is used to execute the script.
• Multi-process version is faster than single-threaded and multi-threaded versions.
• Minimal difference between single-threaded and multi-threaded versions due to the GIL.

"Now I'm just using the regular python command here and as you can see it takes a little while to execute each function you can see that compared to the single-threaded and the threaded version the multiprocess version is actually quite a bit faster and that's because of course it can now use multiple processes in order to handle all these different Prim competitions."

• Multi-processing is significantly faster as it can utilize multiple CPU cores.

• Multi-processing allows the use of multiple CPU cores by creating separate processes, each with its own interpreter and memory space.
• Multi-threading is limited by the GIL, preventing true parallel execution.
• Multi-processing has overhead due to separate interpreter and memory space for each process.

"What you can clearly see is that the difference between single-threaded and multi-thread is actually pretty minimal and that's because of course the GIL is there so you can't really benefit from the multi-threaded possibility."

• The GIL limits the performance benefits of multi-threading, making its performance similar to single-threading.

"If you use the multi-processing module you can indeed use multiple CPU cores because you're creating separate processes but each of these processes is going to have its own python interpreter and its own memory space so you can kind of effectively split things over different CPU cores however you do have the overhead of needing to have a separate interpreter and memory space for each process."

• Multi-processing can utilize multiple CPU cores but introduces overhead due to separate interpreters and memory spaces.

• The GIL has been a long-standing limitation for multi-threaded programs in Python.
• There is increasing demand for making the GIL optional to improve multi-threading capabilities.

"So why is the GIL becoming optional now well it's been requested for a long time and it's become even more requested with."

• There is growing demand for the GIL to be made optional to enhance Python's multi-threading performance.

• The Python community has long been advocating for a solution to the Global Interpreter Lock (GIL) limitations.
• Existing solutions include using libraries like multiprocessing or performing heavy calculations with tools such as NumPy.
• Alternative interpreters like Jython have already removed the GIL.
• There is a desire for these solutions to be accessible in the base language and the most common interpreter, CPython.

"The Python community has been advocating for a solution to the GIL limitations for years now."

• Advocates have been pushing for a solution to the GIL limitations for a long time.

"There are solutions already for this, like using libraries multiprocessing or doing heavy calculations with things like NumPy."

• Current solutions involve using specific libraries or tools to bypass GIL limitations.

"There are even other interpreters like Jython that already removed the GIL."

• Some interpreters have already managed to eliminate the GIL.

• Python version 3.13 or 3.14 will likely introduce a no-GIL build in experimental mode.
• The GIL will still be enabled by default.
• The experimental mode aims to gather insights on usage and performance.
• Users are advised not to rely on this feature in production environments.

"Python version 3.13 or possibly 3.14... the no-GIL build is most likely to be in experimental mode."

• Upcoming Python versions will introduce a no-GIL build experimentally.

"You will still have the GIL by default... developers just want to gain insights into how it's being used."

• The GIL will remain by default as developers collect usage data.

"Really don't rely on that feature in production just yet."

• Users should not depend on the experimental no-GIL build for production use.

• Once the no-GIL builds are stable, they will become a supported option but not the default.
• This stabilization phase is estimated to take one to two years but could be longer.

"In the midterm, once the core team is confident that no-GIL builds are more stable, it's going to become a supported option but still not the default."

• The no-GIL build will be supported but not default once stable.

"The estimation is that this may take a year or two but of course that could be longer."

• The stabilization period is projected to take one to two years.

• The ultimate goal is for the no-GIL build to become the default, eliminating the GIL.
• This transition aims to avoid disrupting backward compatibility.
• The timeline for this goal is up to five years.
• Regular evaluations will ensure progress while maintaining backward compatibility.

"In the long term, the goal is for the no-GIL build to become the default, eliminating the GIL without disrupting backwards compatibility."

• The long-term objective is to make the no-GIL build the default while preserving backward compatibility.

"The team estimates that this could take up to 5 years to reach this stage."

• Achieving this goal is estimated to take up to five years.

"Throughout this process, they'll evaluate regularly to ensure that it's moving along while avoiding backward compatibility struggles."

• Regular assessments will be conducted to ensure progress and compatibility.

• Many packages rely on the GIL for memory safety.
• Removing the GIL could break these packages.
• Frameworks like FastAPI, SQLAlchemy, and Django may be affected.
• Specific dependencies, such as Starlette and AnyIO, which use threading, will need updates.

"Many packages rely on it being present or at least not having to deal manually with memory safety."

• Numerous packages depend on the GIL for memory safety.

"If that goes away, those packages might break."

• Removing the GIL could cause package failures.

"Frameworks like FastAPI, SQLAlchemy, Django are going to be affected by this."

• Popular frameworks may face issues due to GIL removal.

"For example, FastAPI depends on Starlette, which uses AnyIO, which uses the threading and subprocess packages."

• FastAPI and its dependencies illustrate how threading reliance could cause issues.

"I expect this package will need to be updated in order to work correctly in a setting where the GIL is disabled."

• Packages will need updates to function without the GIL.

• The removal of the Global Interpreter Lock (GIL) in Python aims to make the language more parallel-friendly.
• Developers need to be more cautious about thread safety in their programs without the GIL.
• The impact on performance varies across different Python versions and settings.

"Without the GIL, you need to be more cautious about thread safety in your programs."

• Emphasizes the need for increased vigilance regarding thread safety in the absence of the GIL.

• Disabling the GIL shows a significant speed improvement in threaded versions of programs.
• The multiprocessing version is slower in Python 3.13 compared to Python 3.12.
• Single-thread performance also decreases in Python 3.13.

"The threaded version is much faster than the single-thread version, but the multiprocessing version is actually slower than in Python 3.12."

• Highlights the performance improvement in threaded versions but a decrease in multiprocessing and single-thread performance in Python 3.13.

"Single-thread is also slower and not by a little bit; this is actually quite a decrease in performance."

• Points out the notable decrease in single-thread performance in Python 3.13.

• The impact of removing the GIL depends on the specific field of application.
• API development in Python may benefit significantly, with packages like FastAPI becoming faster.
• Data scientists and AI/ML practitioners might see improvements in parallel processing capabilities.
• Simple automation and basic processing tasks may not see a significant difference.

"If you're building APIs in Python, then in the long term, API packages like FastAPI might become even more blazingly fast."

• Suggests that API development could see substantial performance improvements.

"If you're a data scientist or you work in AI/ML, removing the GIL means you'll be able to process data or run AI models in parallel."

• Indicates potential benefits for data scientists and AI/ML practitioners in terms of parallel processing.

"A lot of people use Python for simple automations, connecting tools, basic processing, and tasks, and they don't depend on performance."

• Notes that users engaged in basic tasks may not notice a significant performance change.

• The Python development team continuously works to improve the language.
• Each new version of Python brings enhancements and optimizations.
• Disabling the GIL is an experimental feature and should not be relied upon yet.

"The continuous work of the team behind Python to improve the language is amazing, and Python keeps getting better every new version."

• Praises the ongoing efforts of the Python development team to enhance the language.

"Disabling the GIL in Python is an experimental feature; don't rely on it just yet."

• Advises caution regarding the use of the experimental feature of disabling the GIL.

• Concurrent programming with the asyncio package is another way to optimize Python code performance.
• Additional resources are available for learning about concurrent programming in Python.

"One way to optimize the performance of your Python code is to use concurrent programming with the asyncio package."

• Suggests using asyncio for performance optimization.

"If you want to learn more about that, check out this video next."

• Directs viewers to additional learning resources on concurrent programming.