🐍 Python GIL

DoonDoon·2019년 3월 17일

A thumbnail was created from banner.godori.dev

📚 Contents

🐶 GIL?
🙅‍♂️ 그럼 쓰레드를 쓰지 말까요?
🙄 CPU Bound Task / I/O Bound Task
🎤 Examples
마치며

🐶 GIL?

파이썬을 공부하신는 분들은 GIL 이라는 것을 한 번씩 다 들어 보셨을거라 생각합니다
Global Interpreter Lock 의 약자인 이것은
파이썬 인터프리터가 한 쓰레드만 하나의 바이트코드만 실행할 수 있게 하는 것이죠

GIL은 하나의 쓰레드에게 모든 자원의 점유를 허락합니다
반대로 얘기하면, 다른 쓰레드는 자원을 Acquire 하기 전에는 아예 실행조차 될 수 없다는 뜻이죠

Why GIL?

파이썬의 모든 것은 객체입니다. 그리고 CPython 에서 각각의 객체들은
하나의 C 구조체와 대응됩니다. 결국 엄청나게 객체가 많이 존재한다는 것이죠

각 파이썬 객체는 GC 를 위해 reference count (참조 횟수) 를 가지고 있습니다
reference count 는 병렬 프로그래밍에서 흔히 접할 수 있는
공유 자원 접근시의 rade condition 문제를 겪을 수 있습니다

typedef struct _object { 
    _PyObject_HEAD_EXTRA
    Py_ssize_t ob_refcnt;
    struct _typeobject *ob_type; 
} PyObject;

(위 PyObject 에서 ob_refcnt 가 참조 횟수를 카운팅 하는 값 입니다)

그렇다고, 각 객체가 ob_refcnt 에 접근할 때 마다 개별 mutex 를 활용해서
thread-safe 하도록 만들기에는 성능상의 손해와, deadlock의 위험 등이 존재합니다

그래서 그냥 잠궜습니다. 인터프리터를 잠궜습니다 🔒
많은 글에서 그 당시의 컴퓨팅 환경을 생각하면, 당연한 선택이라고 합니다

아무튼 다시 돌아오면

병렬 프로그래밍에서 얘기하는 작업간의 동기화 정도에 따른 분류를 크게

coarse-grained lock
fine-grained lock

으로 분류하는데, 이는 프로세서의 하위 작업간의 통신의 정도를 의미합니다.
작업간의 동기화와 통신이 잦으면, fine-grained lock 으로 나뉘었다고 하며
그렇지 않다면, coarse-grained lock 으로 나뉘었다고 합니다

파이썬의 GIL은 하나의 쓰레드가 인터프리터의 모든 것을 가져갑니다
굉장히 터프하게 Lock 이 발생하기 때문에
사실상 coarse-grained 또는 embarrassingly parallel(처치 곤란 병렬) 의 형태라 할 수 있습니다

GIL 로 인해 다른 언어와 같이 멀티쓰레딩 프로그래밍이 제한되어
뭔가 성능상의 잇점을 앗아간다고 생각이 드시겠지만
실제로 Single Thread 환경에서의 성능은 좋습니다

그리고 GIL에 대한 개선안에 대하서 귀도 반 로썸은 이렇게 얘기했습니다

But I also don't expect it to go away
until someone other than me goes through the effort of removing it,
and showing that its removal doesn't slow down single-threaded Python code.

~~단일 쓰레드 성능을 저하시키지 않으면서 한 번 개선해서 와봐~~

🙅‍♂️ 그럼 쓰레드를 쓰지 말까요?

파이썬의 쓰레드가 인터프리터를 점유하다가, I/O Bound 작업 (네트워크, 파일I/O 등) 이 발생하면
인터프리터 점유를 release 를 하게 됩니다

만약에, HTTP Request 를 쓰레드를 사용해서 작업하게 된다면
성능 개선이 있을것 같다는 생각이 듭니다

(그 자세한 코드는 아래에서...)

🙄 CPU Bound Task / I/O Bound Task

CPU Bound Task 의 경우에는 파이썬에서 멀티스레드로 구현하는 경우에 같거나 더 느려집니다
더 느려지는 이유는 쓰레드간의 Lock 을 Acquire / Release 하는 과정에서
Context Switching 에 대한 오버헤드가 원인 일것 같습니다

CPU Bound Task 는 CPU 가 처리하면 더 빠른 작업들을 의미합니다... 헤헤
주로 연산작업이 될 것 같고, 사실 I/O Bound Task 를 제외한 것은 모두 CPU 에서 처리하겠죠

I/O Bound Task 는 burst 되는 시간의 대부분을 I/O 에 할애하는 작업을 의미합니다
이를테면, 웹에서 어떤 데이터를 받아오거나, 파일을 읽고 쓰는 등의 작업은 CPU 보다
파일 시스템과 네트워크 등 하위 컴포넌트가 그 작업을 끝내기를 기다리는 시간이 길다는 것이죠

예를 들면, Network 작업, Database I/O, Disk I/O 등이 있습니다
이런 작업을 파이썬 멀티 쓰레드로 구현 한다면 조금 더 성능 개선이 있을 것 같아요

🎤 Examples

동기적으로 (일반적인 형태로) 구글의 연관 검색어 10개를 받아오는 코드를 테스트 했습니다
네트워크 환경에 따라 다르겠지만, 대략 3~4초 정도가 소요 됩니다

urls = [
	'https://www.google.com/complete/search?q=seungri&cp=1&client=psy-ab&xssi=t&gs_ri=gws-wiz&hl=ko&authuser=0&pq=google&psi=ty6OXKGCIMnFmAXDraP4Bw.1552821944139&ei=ty6OXKGCIMnFmAXDraP4Bw',
    # 아래 추가 9개의 url들...
]

@timer # timer 데코레이터는 작업에 소요되는 시간을 프린트 하는 데코레이터 입니다
def fetch_single_thread(urls):
    for url in urls:
        response = fetch(url)
        print(response)

if __name__ == '__main__':
    fetch_single_thread(urls) # Time Elasped 3.02 seconds

아래와 같이 멀티쓰레딩으로 구현한다면, 성능상으로 개선이 될 것이라 생각합니다
결과가 잘 들어왔는지 확인하기 위해 Queue 를 만들어, 결과를 Queue 에 넣습니다
소요시간은 약 0.33 초 입니다

@timer
def fetch_four_threads(urls):
    threads = []
    for url in urls:
        thread = threading.Thread(target=fetch, args=(url,))
        threads.append(thread)

    for t in threads:
        t.start()

    for t in threads:
        t.join()
        
if __name__ == '__main__':
    fetch_four_threads(urls)