[Accepted] PEP 779 - Criteria for supported status for free-threaded Python

원문 링크: PEP 779 - Criteria for supported status for free-threaded Python

상태: Accepted 유형: Standards Track 작성일: 13-Mar-2025

PEP 779 – 스레드-프리 Python의 지원 상태 기준

초록 (Abstract)

PEP 779는 PEP 703 (CPython에서 Global Interpreter Lock (GIL)을 선택 사항으로 만들기)의 구현에 있어 중요한 이정표를 제시합니다. GIL 제거 작업을 위한 3단계 개발 중 2단계, 즉 스레드-프리(GIL-less) Python 빌드를 공식적으로 지원하지만 여전히 선택 사항으로 만드는 단계로 나아가기 위한 명확한 기대치와 요구 사항을 정의합니다. 1단계는 Python 3.13 개발 초기에 시작되었으며, 스레드-프리 빌드를 실험적으로 제공하는 것을 포함합니다. 3단계에서는 스레드-프리 빌드를 기본값으로 설정하게 됩니다.

동기 (Motivation)

PEP 703의 진행 여부, 그리고 궁극적으로 스레드-프리 빌드를 기본값으로 만들 것인지는 비용이 이점보다 큰지 여부에 달려 있습니다. 스레드-프리 Python을 공식적으로 지원되는 빌드로 만드는 것은 디자인이 확정되고, API가 사용 가능하며 안정적이며, 성능 및 복잡성 비용이 과도하지 않다는 신호를 보내는 데 중요합니다. “공식 지원” 단계로 이동하는 것은 스레드-프리 Python을 기본 빌드로, 그리고 결국에는 유일한 빌드로 만드는 중요한 단계입니다. 이 단계를 통해 Python 생태계가 스레드-프리 Python을 지원하는 데 필요한 변경 사항을 적용할 시간을 가지게 되며, 2단계 동안 실제 애플리케이션에서 명확한 이점을 보여주고 성능, 지원 부담 및 생태계 복잡성 측면에서의 비용을 명확하게 정의할 것으로 예상됩니다.

근거 (Rationale)

PEP 703이 수용되기 위해서는 다음 기준들을 만족해야 합니다.

  • 매력성 (Desirability): 스레드-프리 Python은 엄청난 잠재적 이점을 가지고 있습니다. 단순히 기존 코드를 바꾸는 것으로 해결되는 것은 아니지만, 새로운 기능을 최대한 활용하고 성능 저하를 피하기 위해 일부 코드를 재설계하면 더 높은 성능, 현저히 낮은 지연 시간 및 새로운 스레드 기반 기능을 얻을 수 있습니다.
  • 안정성 (Stability): 새로운 API 디자인의 대부분은 3.13에 포함되어 있으며, 여러 서드파티 패키지에서 스레드-프리 Python을 성공적으로 지원하는 데 사용되고 있습니다. 3.14에서는 더 많은 편의 기능이 추가되었고, 이전에 GIL에 의존하던 스레드-안전 API들이 교체되었지만, 3.13의 스레드-프리 Python API를 깨뜨릴 필요는 없었습니다.
  • 유지보수성 (Maintainability): PEP 703 디자인의 대부분은 비교적 간단하며, 대부분의 복잡성은 CPython의 기존 C API 뒤에 숨겨져 있습니다. QSBR (Quiescent State Based Reclamation)에 의존하는 락-프리 리스트 및 dict API와 같은 구현 세부 사항은 복잡할 수 있지만, 사용하기 쉬운 API를 제공합니다.
  • 성능 (Performance):
    • CPU 성능: 스레드-프리 빌드를 GIL이 있는 빌드와 비교했을 때, pyperformance 벤치마크로 측정된 선형 성능 저하는 현재 약 10%입니다 (macOS에서는 약 3%). 현재 진행 중인 몇몇 PR을 통해 Linux 및 Windows에서 10% 미만으로 낮아질 것으로 예상됩니다.
    • 메모리 사용량: gc 모듈 구현 방식의 차이로 인해 정확한 수치는 다르지만, 스레드-프리 Python은 현재 약 15-20% 더 높은 메모리 사용량을 보입니다 (기하 평균, pyperformance 기준). 효율적이고 안전한 스레드-프리 환경을 위한 비용으로, GIL이 있는 빌드의 메모리 사용량에 매우 가깝게 만들기는 어렵습니다.
  • 안정적인 ABI (Stable ABI): 안정적인 ABI 지원은 2단계의 잠재적 요구 사항으로 언급되었지만, 패키지 배포를 훨씬 쉽게 만들 수 있음에도 불구하고 “닭이 먼저냐, 달걀이 먼저냐”의 문제가 있습니다. 2단계는 커뮤니티가 스레드-프리 Python을 채택하고 API 및 ABI에 대한 피드백을 제공할 시간을 주기 위한 것이므로, 안정적인 ABI의 요구 사항 강도는 아직 불확실합니다.

명세 (Specification)

스레드-프리 Python을 공식적으로 지원 (2단계)하기 위한 구체적인 기준은 다음과 같습니다.

  • 수용 가능한 성능: Steering Council은 스레드-프리 Python이 약 10-15% 느릴 것으로 예상했지만, 이는 확정된 목표는 아니었습니다. 현재는 약 10% 수준이며 더 느려질 것으로 예상하지 않지만, 2단계 (기본값 전환 아님)의 경우 15%를 확정적인 성능 목표로 제안합니다.
  • 수용 가능한 메모리 사용량: Steering Council에서 언급되지 않았고 많은 논의가 없었습니다. 2단계의 경우 20% (기하 평균, pyperformance 기준)를 목표로 제안합니다. 3단계의 경우 메모리와 CPU 성능 간의 균형점에 대한 커뮤니티의 의견이 필요할 것입니다.
  • 검증되고 안정적인 API: 측정하기 어려운 부분이지만, 기존 API를 통해 스레드-프리 Python이 상당한 채택을 보였고, 기존 API를 급진적으로 변경할 필요가 없었습니다. 향후 특정 사용 사례를 위한 편의 API가 추가될 수 있지만, 현재 API의 실현 가능성과 안정성은 입증되었다고 믿습니다.
  • 내부 문서화: 스레드-프리 Python 작업을 하는 여러 핵심 개발자가 있지만, 스레드-프리 Python 내부 작동에 대한 입문 문서가 보강될 필요가 있습니다. 이는 Python 3.14에서 달성하는 데 문제가 없을 것으로 예상됩니다.

이러한 기준들이 충족되면, Python 3.14가 PEP 703의 2단계에 적절한 시기가 될 것이라고 믿습니다.

공개 문제 (Open Issues)

안정적인 ABI가 스레드-프리 빌드의 “지원” 상태에 대한 강력한 요구 사항이 되어야 하는지는 여전히 논의 중입니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments