DEVOCEAN

안녕하세요. Teus입니다.

이번에는 소스코드 뜯어보기가 아니라 차기 Python버전에서 기대되는 기능에 대해서 소개해 드릴려고 합니다 :)

이번에 다뤄볼 내용은 what's new in python 3.12에서 등장한 A Per-interpreter GIL입니다.

1. GIL

GIL은 Global Interpreter Lock의 약자로, Python Interpreter는 lock이 존재하고

한순간에 하나의 프로그램(=Thread)만이 인터프리터를 사용할 수 있게 설계되어있습니다.

때문에 MultiThread를 사용해서 한순간에 하나의 Core이상 사용하지 못하는 치명적인 단점을 가지고 있습니다.

현재 MultiCore위주로 발전하고있는 CPU시장에서, single core만 활용할 수 있는 Python의 약점이 계속 커지고 있죠.

<cpu의 Frequency는 증가가 둔해지고, Core의 개수가 늘어가는 CPU market trend>

2. Per-Interpreter GIL

per-Interpreter GIL은 이름으로 알 수 있지만

interpreter마다 GIL을 갖게 만드는 것입니다.

3.12에 실험 모드로 도입(PEP684) 되었으며

3.13버전에 Python Level에서 사용할 수 있게 추가될 것으로 예상(PEP554)되는 기능 입니다.

위 기능에 대한 PEP684를 잠깐 보겠습니다.

주요하게 볼 점은, This allow Python programs to take full advantage of multiple CPU cores입니다.

결국 한순간에 두개 이상의 core를 사용할 수 있게 만들어 줌으로써 GIL의 단점을 상쇄할 수 있는 것이라고 설명되어 있습니다.

안타깝게도 현재는 C-API로만 3.12버전에서 활용해 볼 수 있고, 3.13버전에서 실제 패키지 형태로 추가될 것으로 예상(subinterpreter Module)됩니다.

3. PEP-684

이렇게만 글을 마무리 하기 아쉽죠?

PEP-684 를 통해서 A-per Interpreter GIL가 어떻게 동작하는지 한번 요약해보면 아래와 같습니다.

1. 기존 Python의 문제점들 나열

2. 이중 과거PEP-554에서 제시한 다중 인터프리터 관련 내용에여 영감을 받음

3. 기존 Multicore 활용 방안에 대한 한계점 제시

4. 이를 개선하기 위해서 C-API를 수정해서 Global runtime에 대한 state를 격리시키고,

   다른 state변수들은 PyInterpreterState로 올린다음 GIL을 한단계 인터프리터 수준까지 내리는 내용을 포함

결국 Python Runtime에서 관리하던 GIL을 PyInterpreter수준으로 내리고

Python Runtime에서는 다수의 Interpreter를 활용하여 multicore의 장점을 최대화 하려는 움직임으로 예상이 됩니다.

(확실하지는 않아요!)

여기까지 보면

앵 이거 걍 Process 새로 따는거 아뇨?🤔

라고 생각할만 하지만, PEP 내에서 명백히 Process와는 다르다고 명시해 주고 있습니다.

multiprocessing

too much work to make it effective enough; high penalties in some situations (at large scale, Windows)

일반적인 프로그래밍 에서는

Process

↓

Thread

의 형태를 가지고 있지만

Python의 경우

Process

↓

Interpreter

↓

Thread

의 형태를 가지고 있다고 봐야할것 같습니다.

Thread와 Interpreter가 모두 Process내에서 돌아가지만 Thread 끼리는 메모리를 공유하지만,

Interpreter끼리는 격리가 되어서 메모리를 각자 관리한다가 큰 차이점으로 보입니다.

현재는 Thread만 Python Level에서 다룰 수 있고, interpreter는 3.13버전에서 추가될 것으로 예상됩니다.

출처 : https://thinhdanggroup.github.io/subinterpreter/

그래서 subinterpreter를 적용한 Test버전에서 성능평가를 할 때 아래처럼 subinterpreter>process>thread의 모습을 보여줍니다.

출처 : https://youtu.be/3ywZjnjeAO4?si=tV7dfonNM460l5b9&t=548

※결국 정리하면

Process 대비 subinterpreter를 만드는데 훨신 작은 overhead가 발생한다.

Thread대비 GIL이 없기 때문에 다중코어를 활용 가능하다

라는 점을 이점으로 가지고갈 수가 있습니다.

4. 기타 주저리 주저리

3.12에서 C-API Level에서 per-interpreter GIL을 사용할 수 있게 되었습니다.

3.13에서는 subinterprerter를 Python Level에서 패키지 형태로 사용하는 방법이 제안되고 있습니다.

https://peps.python.org/pep-0554/

결국 3.13에서 subinterpreter가 도입된다고 하더라도

1. List를 만든다

2. List를 Core개수만큼 등분한다

3. Core개수만큼 interpreter가 나눈다

4. 처리한다

의 embrassingly parallism같은 경우는 어려운 것으로 예상됩니다.

(현재는 os.pipe()를 사용해서 serializing된 Data를 주고받는것만 가능하다고 하네요)

다행히 아직 interpreter간 Data통신을 하는 부분은 논의중에 있다고 하니

3.13버전을 기대해볼 만한 매력포인트는 충분하다고 봅니다!

5. 마무리

Python 3.12에서 추가된 per-interpreter GIL이지만, 3.13에서 PEP554가 적용 될지는 아직 확정되지 않았습니다.

Python 3.13의 공개 스케쥴을 아래와 같으니, 연말에 추가되서 멀티코어의 이점을 누리는 Python이 나오길 기원합니다🙏!

(이제 16코어, 22코어의 시대인데 제발..😫)

https://peps.python.org/pep-0719/#schedule
Actual:
3.13 development begins: Monday, 2023-05-22
3.13.0 alpha 1: Friday, 2023-10-13
3.13.0 alpha 2: Wednesday, 2023-11-22
3.13.0 alpha 3: Wednesday, 2024-01-17
3.13.0 alpha 4: Thursday, 2024-02-15

Expected:
3.13.0 alpha 5: Tuesday, 2024-03-12
3.13.0 alpha 6: Tuesday, 2024-04-09
3.13.0 beta 1: Tuesday, 2024-05-07 (No new features beyond this point.)
3.13.0 beta 2: Tuesday, 2024-05-28
3.13.0 beta 3: Tuesday, 2024-06-18
3.13.0 beta 4: Tuesday, 2024-07-16
3.13.0 candidate 1: Tuesday, 2024-07-30
3.13.0 candidate 2: Tuesday, 2024-09-03
3.13.0 final: Tuesday, 2024-10-01 🥳

참고문헌

PEP 554 : https://peps.python.org/pep-0554/

PEP 684 : https://peps.python.org/pep-0684/

a-perinterpreter-gil : https://docs.python.org/3.12/whatsnew/3.12.html#pep-684-a-per-interpreter-gil

https://thinhdanggroup.github.io/subinterpreter/

https://realpython.com/python312-subinterpreters/

https://www.youtube.com/watch?v=3ywZjnjeAO4