---
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
講者於演講後有更新或勘誤投影片的部份