GN⁺: Free-threaded CPython 실험 준비 완료
(labs.quansight.org)- Free-threaded CPython은 동일한 인터프리터 내에서 여러 스레드를 병렬로 실행할 수 있게 하는 큰 변화
- CPython 3.13에서 실험적 기능으로 제공됨
- PEP 703 덕분에 GIL을 비활성화한 상태로 실행 가능해짐
- 성능 향상, 특히 멀티 스레드 성능을 위해 중요함
- 여러 CPU 코어를 효과적으로 활용할 수 있게 함
멋지지만, 문제점은?
- CPython 자체에서 free-threading 구현은 큰 노력임
- 두 가지 주요 문제: 스레드 안전성과 ABI 호환성
- 스레드 안전성: 순수 Python 코드는 변경 없이 작동하지만, 다른 언어로 작성된 코드나 CPython C API를 사용하는 코드는 그렇지 않을 수 있음
- ABI 호환성: free-threaded 인터프리터는 다른 ABI를 가지므로, 확장 모듈이 있는 각 패키지는 추가 휠을 빌드해야 함
- 스레드 안전성 문제는 이해하고 개선하며 테스트하기 어려움
- 예시: numpy#26690, pywavelets#758 등에서 발생한 간헐적 실패
앞으로의 계획 및 팀의 작업
- free-threaded CPython이 기본이 되는 것은 몇 년이 걸릴 것임
- Python 3.13에서 많은 프로젝트가 호환성을 작업하고
cp313t
휠을 PyPI에 릴리스하기를 희망함 - 팀은 몇 달 동안 PyData 스택의 하단부터 작업을 시작함
- 각 패키지에 대해 유사한 접근 방식을 사용함:
- 첫 CI 작업 추가
- 스레드 안전성 및 공유/전역 상태 문제 수정
- 휠 빌드 CI 작업에 free-threaded 지원 추가
- 로컬에서 스트레스 테스트 및 CI 작업 모니터링
- 확장 모듈을 GIL 없이 실행할 수 있도록 표시
- 다음 패키지로 이동
GN⁺의 정리
- Free-threaded CPython은 멀티 스레드 성능을 크게 향상시킬 수 있는 중요한 변화임
- 스레드 안전성 문제와 ABI 호환성 문제를 해결하는 것이 주요 과제임
- Python 3.13에서 많은 프로젝트가 호환성을 작업하고 실험할 수 있기를 희망함
- PyTorch와 같은 주요 패키지와 많은 작은 패키지들이 이 변화를 수용해야 함
- 관련 프로젝트로는 PyO3와 PyTorch가 있음
Hacker News 의견
-
Python의 GIL 제거로 많은 조직과 프로젝트에서 거의 추가적인 노력 없이 성능을 크게 향상시킬 수 있는 기회가 생김
- 오래된 라이브러리가 이러한 변화를 제때 반영하지 않으면 새로운 프로젝트가 시장 점유율을 차지할 가능성이 있음
- 멀티프로세싱의 복잡성과 버그를 피하고 간단한 스레드를 사용하여 큰 머신의 모든 코어를 활용할 수 있게 됨
-
macOS에서 GIL 제거된 Python을 설치하고 작동시킨 경험을 공유함
- 설치 과정과 차이점을 설명하는 짧은 스크립트를 작성함
- 링크
-
Python의 간편한 작성과 논리를 좋아하는 사용자가 GIL 제거된 접근 방식이 기존 Python 작성 방식과 유사하기를 희망함
- 멀티스레딩이 어려워 깊이 파고들지 않았음을 언급함
-
Python 3의 진행 상황을 요약함
- [x] Async
- [x] Optional static typing
- [x] Threading
- [ ] JIT
- [ ] Efficient dependency management
-
2007년경 병렬 처리가 필수적이 되었음을 회상함
- Rust가 속도와 병렬 처리에서 우위를 차지하고 있음을 언급함
-
PEP703에서 GIL 제거 후 리스트의
append
연산이 스레드 안전성을 유지하는 방법을 설명함- 리스트별 잠금이 추가됨
- 간단한 정수 증가 연산이 현재 GIL로 인해 스레드 안전함을 언급함
-
GIL 제거가 ML 훈련과 추론의 성격을 어떻게 변화시킬지 기대함
- 메모리 전달과 프로세스 조정의 복잡성을 줄일 수 있음
- PyTorch와 같은 라이브러리가 최적화될 가능성을 기대함
-
실제 멀티스레딩을 다뤄본 적 없는 프로그래머들이 새로운 미묘한 버그를 도입할 가능성을 우려함
-
단일 스레드 성능 저하가 심각한지에 대한 질문을 제기함
- 벤치마크를 찾지 못했으며, 일반적인 안심만 제공됨
-
async와의 작동 방식에 대한 호기심을 표현함
- I/O와 CPU 바운드 코드 간의 자연스러운 장벽이 있음
- 더 유연한 모델을 보고 싶어함
- CPU 바운드 코루틴에서 "gather"를 수행할 때 JIT가 가능할지 궁금해함
- 유사한 인터페이스로 빠르게 전환할 수 있는 유연한 프로그래밍 모델이 멋질 것이라고 생각함