--- title: "Story About the Python GIL - its existance and the lack there of - Cheuk Ting Ho" tags: PyConTW2025, 2025-organize, 2025-共筆 --- # Story About the Python GIL - its existance and the lack there of - Cheuk Ting Ho {%hackmd L_RLmFdeSD--CldirtUhCw %} <iframe src=https://app.sli.do/event/arRM45hH2fFrk1YocTsXoB height=450 width=100%></iframe> :::success 本演講提供 AI 翻譯字幕及摘要,請點選這裡前往 >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=HTVMyWibomme3MrkhD7a) AI translation subtitles and summaries are available for this talk. Click here to access >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=HTVMyWibomme3MrkhD7a) ::: > Collaborative writing start from below > 從這裡開始共筆 ## Why Python is "SLOW" :::info **Concurrency** Doing multiple tasks ==seemingly== at the ==same== time. ::: - Misunderstanind in "Concurrency" - 2 types of issues: - I/O bound - We use `asyncio` and `threading` - appear concurrent (But not really concurrent) - considering who is in charge - true multithreading without the GIL - CPU bound - Use `multiprocessing` - ture concurrency - side-stepping the GIL - Each process has its own independent Python interpreter - Each process has its own GIL - Different processes can truly execute in parallel on different CPU cores - issue when sharing data among processes ## GIL ### What - ensures that data can only be accessed by one thread at a time - Kind of a lock - a simple solution for **race condition** ### Why do we use GIL - Python is old, design when most PCs only had one core - simplify implementations, no need to consider race condition, memory accessing, easier garbage collection ### Why remove - Community wants faster execution and ==true concurrency== ## Challenges - Reference counting - We assume there's no race conditions with GIL - non-atomic reference counting does not guarantee thread safety - atomic reference counting suggers from high overhead - use biased reference counting, a mixture of both - Garbage Collection - The mechanism to collect unused (reference conuting = 0) objects - Memory allocation - Current memory allocator assumes GIL protection, not thread-safe - A new memory allocator is required: faster read access to list and dict - Compatibility ## Takeaways - We kind of know python is an OK language - Fast in terms of implementation, slow in terms of execution / performance ## Atomic reference counting vs. non-atomic reference counting ### Non-atomic reference counting - Not thread-safe ``` refcount++; // takes 3 steps // 1. read value refcount // 2. add 1 // 3. write value refcount ``` ### Atomic reference counting - Thread-safe - 10x-100x Slower ``` // Not able to be interrupted atomic_increment(&refcount); ``` ### Bias reference counting Check if the counting only belongs to one thread, if so, use non-atomic reference counting, otherwise, use atomic reference counting ## Reference Links - https://peps.python.org/pep-0703/ - https://cheuk.dev Below is the part that speaker updated the talk/tutorial after speech 講者於演講後有更新或勘誤投影片的部份