Hacker News 의견

• 많은 사람들이 멀티프로세싱을 사용하는데, 프로세스 생성 비용이 비싸다는 점 언급

  • SharedMemory 기능이 존재하는데, 왜 더 자주 사용되지 않는지 이해 못함

  • ShareableList 사용 경험이 좋았다는 점 강조

  • 유닉스에서 프로세스 생성 속도는 1ms 미만 수준

    • 하지만 PYTHON 인터프리터 프로세스 시작은 import 개수에 따라 30ms~300ms 걸릴 수 있음
    • 1~2자리수의 차이가 있으므로 정확한 수치 중요
    • CGI는 이 점에서 예외이며, C·Rust·Go로는 문제 없음
    • sqlite.org도 요청당 개별 프로세스 방식 사용 중이라는 예시 공유

  • ShareableList는 원자 스칼라와 bytes·문자열만 공유 가능

    • 파이썬의 구조화된 객체는 pickle dump 등 직렬화 비용 및 프로세스별 복제 메모리 비용 발생

  • numpy 배열 공유에서 큰 성공 경험

    • 명시적 공유 방식은, 스레드 간 실수로 공유해서 발생하는 문제 디버깅 난이도에 비하면 부담 아님
    • 많은 사람들이 스레드가 멀티프로세싱에 비해 얼마나 좋은지 과대평가함
    • GIL이 해제되면 난수성 segfault 디버깅이 늘어날까봐 걱정
    • JavaScript가 공유 메모리 기반 스레딩을 지원하지 않는 것에 사람들이 크게 불평하지 않은 점 언급
    • JavaScript는 속도가 빨라서 그런 필요가 적다는 해석
    • 파이썬의 기본 성능 개선에 더 많은 노력이 필요하다는 바람

  • 프로세스가 독립적으로 죽기 때문에, 락 잡은 채로 공유 메모리 데이터 구조를 수정중이던 프로세스가 죽으면 복구 어렵다는 점

    • Postgres의 공유 메모리 구조와 전체 백엔드 프로세스 종료 필요 예시
    • 스레드는 함께 죽는 구조라서 이런 문제 발생 인식이 덜 하다는 점

  • 공유 메모리는 전용 하드웨어에서만 동작

    • AWS Fargate 같은 환경에서는 공유 메모리 없음, 네트워크 또는 파일시스템 사용 필요로 인해 레이턴시 증가
    • fork 방식의 프로세스 복제는 또 다른 문제
    • 실제 경험상 green thread와 actor 모델이 훨씬 더 효과적이었다는 주장

• GIL 제거가 파이썬 멀티스레드 코드에 병렬 처리 외에 다른 영향이 있는지 궁금함

  • GIL이 유지된 이유는 멀티스레드가 GIL에 의존해서가 아니라, GIL 제거가 인터프리터 구현과 C 확장, 단일 스레드 코드 속도 저하를 유발하기 때문이라는 이해

  • Free-threaded Python이 bytecode 경계에서 언제든 선점될 수 있다는 기존 보장과 동일한지 궁금

  • 아니면 락을 더 써야 하는 등 작성 방식이 달라지는지 궁금

  • free-threaded Python도 대부분 같은 보장

    • 다만, free-threading이 없으면 사람들이 스레딩 기능을 덜 쓰고, 경계에서 선점되는 버그가 실제로 잘 발생 안함
    • free-threading 도입 시 더 많은 버그 노출
    • 멀티프로세스 우회 방법을 쓸 필요가 없어져 유저 코드가 간단해짐; 인터프리터 복잡성 증가의 가치가 충분하다고 생각
    • C 확장 복잡화 문제는 free-threading보다 sub-interpreter가 더 심함; numpy팀이 sub-interpreter는 지원 못한다고 명확히 밝힘
    • numpy는 이미 free-threading 지원, 남은 버그 수정 중
    • 단일 스레드 속도 약간(한자리수 %) 느려지는 건 감수할 만한 트레이드 오프

  • 멀티코어 사용은 가능하나, 스레드당 성능 저하와 라이브러리 재작업 필요

    • PyTorch로 실험 시, 10배 CPU 사용에 절반의 작업 처리량 경험
    • 시간이 지나며 개선 기대, 20년 간 이걸 기다려온 만큼 반가움

  • 경쟁상황(레이스 컨디션)이 더 빈번하게 발생할 수 있으니, 신뢰도 보장을 위해 멀티스레드 파이썬 작성에 더 많은 주의 필요

• Microsoft가 Faster Python 팀을 해산했다는 소식 전달

  • 2025 예상 실적 미달로 팀 유지 안됐던 것

  • 향후 CPython에 성능 개선이 추가되는지, 혹은 타사가 후원하는지 지켜볼 예정

  • Facebook(메타)는 아직 일부 후원 중인 것으로 보임

  • Microsoft의 약속 대비 일정이 크게 지연되었던 점 언급

    • 최근에는 심각한 정치·거버넌스 문제를 알고 있을 것; 유능한 직원이 괜히 기여해 그룹 비방을 당하고 싶지 않을 것이라는 의견
    • CPython 조직이 약속 과다, 순응파에 일거리를 몰아주고 유능한 반대자를 내몬다는 비판
    • 과거에는 이런 문제가 없었음, 현재 스스로 야기한 문제

  • 이런 결과는 아쉽지만, Microsoft의 장기 약속을 신뢰하지 않았던 본인의 예상이 맞았다는 언급

  • 최근 Google도 전체 파이썬 개발팀을 해고한 것 같다는 소문

    • 둘 다 시대적 원인이나 공통 분모가 있는지 궁금

  • 매우 안타깝지만, embrace & extend 이후 남은 건 하나뿐이라는 뉘앙스

• 파이썬에서 GIL이 사라지는 걸 걱정하는 사람이 자신뿐인지 궁금

  • 어떤 언어든 복잡한 멀티스레드 코드는 신뢰 어렵고, 파이썬은 동적 특성상 특히 더 불안

  • 혼자만 변화에 대한 두려움이 있는 게 아니며, 근거가 비합리적일 수 있다는 점

    • GIL이 순수한 기술부채이니, 커뮤니티 이익을 위해 제거 필요
    • 요즘 파이썬에서 대부분 스레드 대신 non blocking IO와 async 사용
    • 스레드 사용 안하면 GIL 제거로 인한 변화 없음; C 라이브러리도 단일 스레드로 안전
    • 스레드 실제로 사용하면만 주의 필요
    • 나이브한 스레드 파이썬 코드는 지금까지 GIL에 막혀 단일 스레드처럼 동작했는데, 이제는 좀 빨라지되, 버그가 늘어날 수도 있음
    • 해결책은 스레드를 안 쓰거나, 쓰려면 제대로 배우면 된다는 조언
    • 앞으로 더 좋은 추상화 제공될 테니, 커뮤니티에서 structured concurrency 등 논의 기대

  • 본인은 asyncio를 적극 사용하고 있음

    • 싱글 스레드이지만 concurrent한 파이썬을 즐겁게 작성 가능; Node.js처럼 사용
    • 웹·네트워크 작업에는 이런 방식 추천

  • ML/AI 분야에서처럼 전문가가 복잡 라이브러리를 먼저 만들고, 일반 사용자에겐 그것을 전달하는 구조 예상

    • 파이썬의 GIL이 심각한 병목이 되는 경우들이 많아졌음
    • 그래서 Go 언어를 배움; 스레드 지원 제대로 되는, 파이썬보다 하위, C/C++보다는 상위 추상화라 할 수 있음
    • 컴파일러 방식도 스레딩 못지 않게 중요한 배경

  • 괜한 불안 조장이 될 수도 있지만, LLM이 지난 수십 년간의 GIL 존재 가정 하의 파이썬 코드로 학습된 사실 상기

  • GIL 유무는 멀티코어 작업을 원하는 사람에게만 해당

    • 현재도 스레딩·멀티프로세싱에 신경 쓰지 않았다면 실질적 변화 없음
    • 레이스 컨디션 이슈는 GIL 유무와 상관 없이 발생

• 파이썬을 자주 사용하지만 전문가 아니며, 가끔 concurrent.futures로 단순 함수 여러 개 동시 실행

  • 이런 사용자가 앞으로 무엇을 바꿔야 하는지 궁금

  • 스레드가 GIL에 묶이지 않아 전체적으로 더 빨라짐

    • 공유 객체 락만 제대로 처리했다면 추가 걱정 불필요

• 20년간 파이썬으로 프로 개발 경험에서 느끼는 점 공유

  • 스레드가 진짜로 필요할 때는 메시지 패스가 불가피한 경우에 한정

    • 파이썬 생태계가 이미 이런 모든 상황의 우회책 제공
    • 여러 스레드 핸들링 함정(락 등) 때문에, 앞으로 특정 라이브러리·도메인에서만 필요할 수 있음
    • 순수 파이썬만으로 최대한 성능 뽑아내려면 native code 기반 라이브러리(ex. Pypy, numba) 활용 가능
    • 파이썬의 성능 혁신은 결국 async 프로그래밍; 꼭 배워보길 추천

  • 파이썬을 비슷하게 오래 썼고 동의하지만, 약간 다르게 표현

    • 파이썬 스레드가 워낙 별로라서, 피하기 위한 다양한 우회책이 발전
    • CPU-bound 작업을 스레드로 2배 빨리하려다 GIL 문제에 부딪혀, 멀티프로세싱으로 전환; 데이터 구조 직렬화로 인한 비용 발생, 2배 코어에 1.5배 속도 등 비효율적 경험
    • 좋은 스레드 지원이 생기면 활용하고 싶은 환경 많음; 여태 없으니 각종 대체 접근법을 썼다는 점
    • 상황에 맞으면 async 활용 강력 추천(글리프, 당신 말이 맞았어요!)

• AI 이미지이지만, 뱀에 꼬리가 두 개 그려진 것 의아함

  • 조용히 넘어가라는 찬조 의견; 파이썬 기사에 뱀 그림 들어가면, 대체로 딱히 신경 쓸 가치 없는 신호라고 유희적으로 언급

  • 'Confusoborus'라는 농담식 명칭 제안

• 헤더 이미지의 뱀이 두 개의 꼬리를 가진 듯하다는 지적

  • 같은 프로세스 내에서 두 번째 스레드를 생성한 모양이라는 익살

• 라이브러리 지원 외에, WSGI와 Celery 워커를 단일 프로세스로 띄우는 것에 다른 제약이 있는지 궁금

  • 제약은 없으나, 이런 방식이 언어의 1급 기능이 아니라는 점
    • GIL은 기술부채 이슈라는 설명
    • 병렬성 외에도 GIL 해제가 필요한 요소 존재

• 앞으로의 성능 시대를 위한 엄청난 기반 작업이라고 생각