Onkar Lapate’s Post

Why it took nearly 30 years to have no-GIL Python versions? TL;DR: The Single-Thread Tax In the past, every time someone tried to remove the GIL, the standard Python code got 30-50% slower for making refcounting thread safe. How was this solved in Python 3.13+ versions? The move to No-GIL isn't just about deleting the lock. It’s about Biased Reference Counting and Immortal Objects. -> Immortal Objects: Things like True, False and None now have a special status where their reference counter never changes. This means threads don't have to fight over them. So single thread tax is out of question. -> Biased Counting: Python now assumes that the thread that created an object is the one that will use it most. It handles that thread’s counting differently than other(guest) threads. So this finally reached a point where the "Single-Thread Tax" is down to about 5-10%. This approach has real limitations (especially for cross-thread sharing). Will discuss them in next posts. I am trying to learn Python Internals in detail and will share my learnings. Do follow along and tell your experiences in comments. #Python #PythonInternals #SoftwareEngineering #BackendDevelopment

  • graphical user interface, application

To view or add a comment, sign in

Explore content categories