블로그 글에 포함되었으면 좋았을 핵심 코드 조각을 공유함
MSVC와 Clang의 musttail 및 preserve_none 속성 정의 차이를 보여주는 예시임
이 속성은 함수 선언자에 붙여야 하며, 함수 지정자 위치에서는 동작하지 않음 관련 코드 링크
Microsoft가 중요하다고 판단한 프로젝트에만 이런 비공개 기능을 알려주는 듯한 뉘앙스를 풍김
내가 착각했음. [[msvc::musttail]]은 실제로 공식 문서화된 속성이었음
블로그 글을 수정해 반영할 예정임 관련 HN 댓글
“중요해서 알려준 걸까, 아니면 자기들에게 이익이 되니까 알려준 걸까?”라는 의문을 제기함
예전 Python 3.14 때처럼 LLVM 19 버그로 인해 잘못된 성능 향상이 보고된 사례를 떠올리며, 이번엔 그런 문제가 없길 바람
글을 읽어보니 투명성과 빠른 피드백을 우선시한 접근이라 괜찮다고 판단함
교차 컴파일러 검증이나 독립 감사가 있으면 더 좋겠지만, 저자의 완전한 투명성 덕분에 신뢰할 수 있다고 봄
글쓴이는 그때의 실수가 오히려 행운의 사고였다고 회상함
일찍 공개했기에 Nelson이 Clang 19 버그를 찾아냈고, 덕분에 정식 릴리스 전에 수정할 수 있었음
이번엔 dispatch 로직과 inlining 두 가지 개선이 있어 더 자신 있음
MSVC가 특정 조건에서 switch-case 인터프리터를 threaded code로 바꿀 수 있지만, CPython은 너무 복잡해서 해당 최적화가 적용되지 않음
대신 tail call 접근법은 C 코드 작성자가 더 많은 제어권을 가짐
관련 참고: MSVC threaded code 조건, forceinline 관련 이슈
새 설계의 장점은 컴파일러 최적화의 변덕에 덜 의존한다는 점임
과거엔 tail duplication 같은 최적화가 컴파일러 판단에 따라 달라졌지만, 이제는 인터프리터가 직접 원하는 머신 코드 형태를 표현할 수 있음 이전 논의 링크
오랜만에 Windows용 GUI 앱을 Python으로 만들고 있음
C#/MAUI보다 VS 생태계가 너무 무거워서 Python을 선택함
Tkinter는 불편했고, Qt는 학습 부담이 커서 wxGlade + wxPython 조합을 사용함
pip로 설치 가능한 단일 의존성만 필요하고, Pythonic한 사용감이 마음에 듦
Windows 런타임 개선이 반가움
나는 Python + Qt/PySide 조합을 선호함
QtCreator로 UI를 빠르게 만들고 Python으로 로직을 붙이면 개발 속도가 매우 빠름
pyfltk도 추천함. GNU/Linux에서는 꽤 괜찮았음
GUI가 중요하다면 LINQPad도 고려할 만함. 스크립팅과 무거운 작업 사이의 중간 지점에 있음
Python용 ImGui 바인딩을 추천함
Tkinter나 Qt처럼 retained mode가 아니라 immediate mode 방식이라 내부 툴링에 특히 유용함 imgui_bundle 프로젝트
“이 정도면 낮은 난이도의 최적화 과제 아닌가?”라며, 왜 아직 인터프리터 루프가 완전히 최적화되지 않았는지 의문을 제기함
주요 ISA별로 어셈블리로 작성되어 있을 줄 알았다고 함
오히려 이번 업데이트는 루프가 이미 극도로 최적화되어 있음을 보여준다고 생각함 [[msvc::musttail]]은 MSVC 14.50(지난달 출시)에 추가된 최신 속성인데, CPython 팀이 몇 주 만에 이를 활용해 성능 향상을 이뤘음 MSVC musttail 문서
Python은 애초에 속도보다 단순함을 목표로 함
Guido가 코드 단순성을 우선시했기에 JIT 도입이 늦었고, 이후 PEP 744(JIT Compilation) 같은 시도가 나옴
오픈소스에 과도한 기대를 하지 말아야 함
어셈블리 최적화는 유지보수 악몽이며, Python의 진짜 병목은 패키징 시스템임
어차피 성능에 민감한 사람들은 Windows에서 Python을 돌리지 않음이라 언급함
“왜 Python 인터프리터는 V8보다 훨씬 느린가?”라는 질문 제기
JavaScript는 JIT 컴파일을 사용하지만 CPython은 그렇지 않음
PyPy는 JIT 덕분에 빠르지만 C 확장과 호환되지 않음
Python의 스레딩 모델도 최적화를 어렵게 함
반면 JS는 단일 스레드라 단순함
Python은 C 확장으로 우회할 수 있어 CPython 자체 최적화에 대한 압박이 적었음
Google의 인력과 품질이 큰 차이를 만든다고 봄
또한 CPython은 방대한 C 확장 생태계 때문에 호환성을 깨지 못함
반면 V8은 내부 구조를 자유롭게 바꿀 수 있었음
Python은 속성 접근조차 descriptor 프로토콜을 거치는 등 훨씬 동적임
또한 안정적인 C ABI를 유지해야 해서 JIT이 자유롭게 코드 분석을 하기 어려움
Python은 JS보다 훨씬 동적 언어이고, FFI 바인딩 때문에 내부 변경이 제한됨
PyPy가 이런 제약을 맞추느라 고생한 사례를 언급함
JS는 Google이 웹을 지배하기 위해 막대한 자원을 투입해 최적화했지만, Python은 언어 발전에 더 많은 리소스를 써왔음
또한 JS는 순수 JS만 지원하면 되지만, Python은 외부 확장 생태계를 유지해야 해서 최적화에 제약이 많음
새로운 벤치마크 그래프가 흥미롭다고 언급하며 어떤 도구로 생성했는지 질문함
자신은 mitata로 JS 라이브러리 성능을 측정한 경험이 있다고 공유함 Immer JS 최적화 PR
그 그래프는 violin plot임 Wikipedia 설명, Matplotlib 예시
분포를 대칭으로 시각화하지만, 스무딩이 실제 분포를 왜곡할 수 있고, 공간 낭비라는 비판도 있음 HN 논의에서는 half-violin plot이 더 낫다는 의견도 있었음 예시 이미지
Matt Godbolt이 tail-call 기반 인터프리터가 CPU의 분기 예측기(branch predictor) 에 더 잘 맞는다고 언급했음을 전함
글 첫 문장에 오타 두 개가 있는데, 혹시 AI 생성 티를 내기 위한 의도적 실수인지 묻는 댓글임
작성자는 “고마움, 수정했음”이라 답함
다른 사용자는 “AI처럼 보이지 않게 하려면 그냥 직접 쓰면 된다”고 농담 섞인 조언을 함
AI 글의 전형적인 특징(짧은 문단, 과한 긍정 어조, 깊이 부족 등)을 풍자함
“Python 팀이 tail call을 유용하다고 본다면, 언어 자체에도 tail call 지원이 들어올까?”라는 질문을 던짐
Hacker News 의견들
MSVC와 Clang의
musttail및preserve_none속성 정의 차이를 보여주는 예시임이 속성은 함수 선언자에 붙여야 하며, 함수 지정자 위치에서는 동작하지 않음
관련 코드 링크
Microsoft가 중요하다고 판단한 프로젝트에만 이런 비공개 기능을 알려주는 듯한 뉘앙스를 풍김
[[msvc::musttail]]은 실제로 공식 문서화된 속성이었음블로그 글을 수정해 반영할 예정임
관련 HN 댓글
글을 읽어보니 투명성과 빠른 피드백을 우선시한 접근이라 괜찮다고 판단함
교차 컴파일러 검증이나 독립 감사가 있으면 더 좋겠지만, 저자의 완전한 투명성 덕분에 신뢰할 수 있다고 봄
일찍 공개했기에 Nelson이 Clang 19 버그를 찾아냈고, 덕분에 정식 릴리스 전에 수정할 수 있었음
이번엔 dispatch 로직과 inlining 두 가지 개선이 있어 더 자신 있음
MSVC가 특정 조건에서 switch-case 인터프리터를 threaded code로 바꿀 수 있지만, CPython은 너무 복잡해서 해당 최적화가 적용되지 않음
대신 tail call 접근법은 C 코드 작성자가 더 많은 제어권을 가짐
관련 참고: MSVC threaded code 조건, forceinline 관련 이슈
과거엔 tail duplication 같은 최적화가 컴파일러 판단에 따라 달라졌지만, 이제는 인터프리터가 직접 원하는 머신 코드 형태를 표현할 수 있음
이전 논의 링크
C#/MAUI보다 VS 생태계가 너무 무거워서 Python을 선택함
Tkinter는 불편했고, Qt는 학습 부담이 커서 wxGlade + wxPython 조합을 사용함
pip로 설치 가능한 단일 의존성만 필요하고, Pythonic한 사용감이 마음에 듦
Windows 런타임 개선이 반가움
QtCreator로 UI를 빠르게 만들고 Python으로 로직을 붙이면 개발 속도가 매우 빠름
Tkinter나 Qt처럼 retained mode가 아니라 immediate mode 방식이라 내부 툴링에 특히 유용함
imgui_bundle 프로젝트
주요 ISA별로 어셈블리로 작성되어 있을 줄 알았다고 함
[[msvc::musttail]]은 MSVC 14.50(지난달 출시)에 추가된 최신 속성인데, CPython 팀이 몇 주 만에 이를 활용해 성능 향상을 이뤘음MSVC musttail 문서
Guido가 코드 단순성을 우선시했기에 JIT 도입이 늦었고, 이후 PEP 744(JIT Compilation) 같은 시도가 나옴
어셈블리 최적화는 유지보수 악몽이며, Python의 진짜 병목은 패키징 시스템임
PyPy는 JIT 덕분에 빠르지만 C 확장과 호환되지 않음
Python의 스레딩 모델도 최적화를 어렵게 함
반면 JS는 단일 스레드라 단순함
Python은 C 확장으로 우회할 수 있어 CPython 자체 최적화에 대한 압박이 적었음
또한 CPython은 방대한 C 확장 생태계 때문에 호환성을 깨지 못함
반면 V8은 내부 구조를 자유롭게 바꿀 수 있었음
또한 안정적인 C ABI를 유지해야 해서 JIT이 자유롭게 코드 분석을 하기 어려움
PyPy가 이런 제약을 맞추느라 고생한 사례를 언급함
또한 JS는 순수 JS만 지원하면 되지만, Python은 외부 확장 생태계를 유지해야 해서 최적화에 제약이 많음
자신은
mitata로 JS 라이브러리 성능을 측정한 경험이 있다고 공유함Immer JS 최적화 PR
Wikipedia 설명, Matplotlib 예시
분포를 대칭으로 시각화하지만, 스무딩이 실제 분포를 왜곡할 수 있고, 공간 낭비라는 비판도 있음
HN 논의에서는 half-violin plot이 더 낫다는 의견도 있었음
예시 이미지
AI 글의 전형적인 특징(짧은 문단, 과한 긍정 어조, 깊이 부족 등)을 풍자함