실험적 JIT, PEP 836 철회로 CPython에서 제거 수순

파이썬이 제일 좋아하는 언어인데 성능 병목은 맨날 Cython이나 Rust로 다시 짜야 해서 지침. 마크 섀넌이 약속했던 속도 개선도 결국 위원회 절차에 발목 잡힌 것 같아서 답답함.

Unladen Swallow도 업스트림 관심 없어서 죽었고 PyPy는 NumPy가 지원 끊었잖아. 이번 JIT도 같은 이유로 죽는 걸 보니 낙관적이지 않음.

요즘은 Claude한테 병목 부분 Rust로 다시 짜달라고 하는 게 잘 먹혀서, 굳이 코어에 JIT 넣을 이유가 있나 싶기도 함.

그 위원회 절차가 언어를 안 망치게 만든 거 아님? 스펙 제대로 안 된 걸 프로덕션에 넣으면 안 되지. 실험은 허용했는데 제안자들이 볼을 떨어뜨린 거임.

효율 얘기 나오면 생각나는 게, 첫 AI 붐은 Lisp이랑 Prolog로 돌았고 둘 다 50년 전부터 기계어 생성 지원했음.

이건 레드테이프가 아니라 약속한 걸 실제로 계속 전달할 수 있는지 확인하는 절차임. 초안 PEP 상태를 보면 그게 안 되니까 운영위가 못을 박은 거지.

기술적으로 재밌는 기능이 절차랑 개발자 개인 시간 부족으로 죽는 건 아쉽지만, PEP 정책 덕에 파이썬이 지금 상태가 된 것도 사실. 디버거랑 계측 지원 유지보수가 만만찮다는 지적도 일리 있음.

V8에서 JIT 관련 타입 혼동 보안 버그 터진 거 보면 다른 개발자들이 꺼리는 것도 이해됨.

이걸 그냥 관료제 탓으로 돌리는 건 오해임. 운영위는 도구로 절차를 쓴 거고, 실제로 유지보수와 호환성, 성공 지표를 설득력 있게 제시하지 못해서 철회된 거잖아.

큰 코드베이스 자체가 관료제라서, 사람 쪽 절차가 소프트웨어 복잡도를 적당히 눌러준 셈임. 범위랑 영향 확인 요청은 합리적이었고 제안자들이 못 하겠다고 한 거지.

핫테이크 하나: 파이썬 JIT는 첫 단계부터 너무 크게 잡음. 성공하려면 hidden type model부터 만들어서 해시테이블 조회를 상수 시간 guard + offset 조회로 바꿔야 함. dict 의미론이랑 스코프 객체의 * 동작 보존이 진짜 어려운 부분임.

파이썬 3000에서 하위 호환 깨겠다고 할 때 이런 토대라도 좀 깔아뒀어야 하는 거 아닌가 싶음.

해시테이블 조회 최적화는 이미 LOAD_ATTR_INSTANCE_VALUE나 LOAD_ATTR_SLOT 같은 opcode 특수화로 상당 부분 하고 있음.

이유를 보면 합리적인 결정 같음. 성능이 중요하면 파이썬을 안 쓰면 되고, Cython이나 Numba, PyPy, C 확장 같은 우회로가 이미 많잖아.

그 우회로들은 다 각자 구멍이 있어서, 우리는 순수 파이썬이 빨라지길 원하는 거임.

PyPy는 사실상 생명 유지 장치 상태임. 최근 메이저 버전도 몇몇 회사랑 개인이 직접 업데이트해서 나온 걸로 앎.

실험 기능으로 2년 넣어두고 빼는 거면 별문제 아님. 코어에 JIT 들어가는 건 큰일이니까 신중한 게 맞지.

오히려 이렇게 된 게 문제임. 어려운 질문을 미리 안 하고 강행했으니 운영위가 손을 강제당하는 걸 싫어한 거지.

Rust로 만든 RustPython 쪽은 JIT 유지해도 되고, 함수 단위 on-demand라 명시적으로 켜야 해서 CPython보다 안전할 수도 있음.