SPy의 동기와 목표를 설명하며, 왜 Python은 근본적으로 최적화하기 어려운지, 기존 접근법의 한계와 SPy가 제시하는 방향을 살펴봅니다.
spy 이 글은 SPy에 대해 깊이 있게 설명하려는 연재의 첫 번째 글입니다. 동기, 목표, 언어의 규칙, Python과의 차이점, 그리고 구현 세부 사항을 다룰 예정입니다.
이 글은 주로 문제 공간에 초점을 맞춥니다. 왜 Python은 근본적으로 최적화하기 어려운지, 기존 해법들이 어떤 트레이드오프를 요구하는지, 그리고 현재 접근법이 어디에서 한계를 드러내는지를 살펴봅니다. 이 연재의 다음 글들에서는 해법을 깊이 있게 탐구할 것입니다. 우선은 가장 본질적인 질문부터 시작해 봅시다. SPy란 무엇일까요?
본론에 들어가기 전에, 이 오픈소스 프로젝트에 제 시간을 100% 쏟을 수 있는 기회를 준 제 고용주 Anaconda에 감사의 뜻을 전하고 싶습니다.
관점에 따라 여러 가지 답이 가능합니다. 기술적으로 가장 정확한 답은 다음과 같습니다.
SPy는 성능에 초점을 맞춘, Python의 정적 타입 변형을 위한 인터프리터이자 컴파일러입니다.
처음부터 분명하고 솔직하게 말하는 것이 매우 중요하다고 생각합니다. SPy는 "Python용 컴파일러"가 아닙니다. Python 언어에는 설계상 SPy가 결코 지원하지 않을 기능들이 있습니다. Django나 FastAPI를 SPy로 컴파일할 수 있으리라고 기대하지 마세요.
작은 귀결로, 적어도 지금은 두 세계의 구분을 매우 분명하게 하기 위해 SPy 프로그램은 *.spy 파일에 두기로 했습니다.
Python 100%를 컴파일하는 것이 목표는 아니지만, SPy는 기존 Python 생태계와 매우 긴밀하게 통합되는 것을 목표로 합니다. SPy에서 Python 라이브러리를 import할 수 있고, Python에서 SPy 모듈을 가져올 수도 있습니다.
100% 호환성이라는 신화
과거와 현재에 존재했던 "Python용 컴파일러"의 대다수는 "100% 호환"이 아닙니다. 그렇게 주장하더라도 전체 언어를 지원하지는 않습니다. SPy는 이 점을 더 명시적이고 솔직하게 드러내는 쪽을 택합니다.
Current Status
SPy는 아직도 한창 개발 중이며, 계획과 설계의 일부이지만 아직 구현되지 않은 것들이 많습니다.
이 연재를 읽기 쉽게 하기 위해, 저는 SPy의 기능을 말할 때 항상 현재형을 사용합니다. 아직 구현되지 않은 경우에도 그렇고, 더 자세한 설명은 이런 "Current Status" 상자에 미룹니다.
현재 시점에서 SPy는 데모보다 큰 무언가에 쓰기에는 아직 사용할 수 없습니다. SPy로 작성된 가장 복잡한 코드는 아마 raytracing example일 것이며, 이것은 CPython보다 200배 빠릅니다.
Current Status: Python integration
이 글을 쓰는 시점에서 SPy는 아직 Python 라이브러리를 import할 수 없습니다. 계획은 libpython.so를 내장해 이 사용 사례를 지원하는 것입니다. 물론 필요할 때만 그렇게 할 것입니다. 하지만 그러려면 SPy에서 C를 호출할 수 있는 방법이 필요하고, 그것은 아직 구현되지 않았습니다.
반대 방향은 부분적으로 지원됩니다. SPy 컴파일러는 CPython에서 import할 수 있는 CFFI 기반 확장을 생성할 수 있습니다. 이는 실험과 초기 테스트에는 유용하지만, 부분적이고 저수준 API만 노출합니다. 궁극적으로 SPy 컴파일러는 Cython이 하는 것과 비슷하게 완전한 CPython 확장을 생성할 수 있게 될 것입니다.
또 다른 가능한 답은 다음과 같습니다.
SPy는 Python다움을 유지하면서 Python에서 얼마나 많은 동적성을 제거할 수 있는지를 알아보기 위한 사고 실험입니다.
수년 동안 Python 속도를 높이려는 많은 시도가 있었습니다. 일반적으로 두 범주로 나뉩니다.
"완전한 Python"을 구현한다. 모든 동적 기능을 지원하면서도 빠르기 위해, 보통 Just In Time(JIT) 컴파일러를 사용합니다. 예로는 PyPy, GraalPy, Pyston, 그리고 CPython's own JIT가 있습니다.
빠른 코드를 생성할 수 있는 Ahead of Time(AOT) 또는 JIT 컴파일러로서 "Python의 부분집합" 또는 "Python의 변형"을 구현한다. 여기서의 일반적인 접근은 Python을 컴파일하기 어렵게 만드는 동적 기능을 많이, 경우에 따라서는 전부 제거하는 것입니다. 예로는 RPython, Mypyc, Cython, Numba가 있습니다.
"완전한 Python" JIT 컴파일러의 문제는, 어떤 때는 아주 잘 작동해서 엄청난 속도 향상을 내지만, 다른 때는 전혀 속도 향상이 없거나 오히려 느려질 수도 있고, 메모리를 너무 많이 쓰거나, "워밍업"에 시간이 걸릴 수 있다는 점입니다.
부분집합/변형 접근의 문제는 Python의 동적 기능을 제거하다 보면 결국 _파이써닉_하다고 느껴지지 않는 무언가가 된다는 점입니다. 그리고 전형적이고 관용적인 Python 패턴의 다수가 그냥 작동하지 않습니다. 흔히 "Python 문법을 한 Java" 같은 결과로 끝납니다. Java 자체를 비난하려는 뜻은 전혀 아니지만, 제가 무슨 뜻인지 감을 드리길 바랍니다.
SPy는 다른 일을 합니다. 한편으로는 Python을 "느리게" 만드는 동적 기능을 제거하지만, 다른 한편으로는 우리가 좋아하는 바로 그 파이써닉한 패턴을 구현하고 사용할 수 있게 해 주는 새로운 기능을 도입합니다. 이 결과를 어떻게 달성하는지는 몇 문장으로 설명할 수 없고, 그래서 연재 전체가 필요한 것입니다 :).
Subset vs Variant
컴파일러가 Python의 부분집합을 구현한다면, 컴파일 가능한 모든 프로그램은 CPython 위에서도 실행될 수 있습니다. 만약 그 컴파일러가 CPython에는 없는 새 기능도 추가한다면, 그것은 변형입니다.
예를 들어 이 정의에 따르면 RPython은 부분집합이고 Cython은 변형입니다. SPy 역시 변형입니다. 나중에 보겠지만 고유한 기능을 제공하기 때문입니다.
위에서 말했듯이, Python과의 100% 호환성은 명시적으로 목표가 아닙니다.
만약 여러분이 속성 조회 로직의 내부 세부 사항이나, 내장 타입을 상속할 때 Python이 언제 __add__를 호출하고 언제 __radd__를 호출하는지를 아는 "언어 덕후"라면, SPy는 분명히 Python이 아니며, 그렇게 되려고 시도조차 하지 않습니다.
하지만, 많은 Python 사용자에게는 그것이 중요하지 않으리라 생각합니다. 다른 사람이 작성한 복잡한 라이브러리를 주로 사용하고 "직관적인" Python 코드를 작성하는 사용자들이 많습니다. 그런 사람들에게는 SPy를 쓰는 일이 Python을 쓰는 것만큼 쉬워야 합니다.
다음은 SPy의 목표와 설계 지침 목록입니다.
사용과 구현이 쉽다. 언어는 이해하기 쉬워야 합니다. 또한 대규모 엔지니어링 팀 없이도 SPy를 구현할 수 있어야 합니다.
개발과 디버깅의 편의를 위해 인터프리터를 둡니다.
배포와 성능을 위해 컴파일러를 둡니다. 인터프리터와 컴파일러는 런타임에 정확히 동일한 결과를 내는 것이 보장됩니다.
정적 타이핑. 타입 애너테이션은 언어 차원에서 강제되며, 인터프리터와 컴파일러가 모두 이를 검사합니다.
성능은 중요하다. SPy는 C나 Rust 같은 저수준 언어에 필적하는 성능을 목표로 합니다.
예측 가능한 성능. 우리가 완전히 이해하지 못하는 "마법 같은 최적화기"에 의존하지 않고도, 그리고 코드 한 줄을 수정했더니 전체가 10배 느려지는 "성능 절벽" 없이도, 특정 코드 조각의 성능 특성을 추론할 수 있어야 합니다.
풍부한 메타프로그래밍 능력. SPy는 메타프로그래밍을 일급으로 지원하지만, 정확한 문법과 특성은 Python과 다를 수 있습니다. 예를 들어 SPy에서도 FastAPI나 SQLAlchemy 같은 것을 충분히 다시 만들 수 있습니다.
제로 코스트 추상화. SPy는 데코레이터, **kwargs, 디스크립터 프로토콜, __getattr__ 등을 추가 런타임 비용 없이 지원합니다.
옵트인 동적성. Python의 일부 동적 기능은 기본적으로 꺼져 있지만, 필요할 때는 명시적으로 켤 수 있습니다. 예를 들어 SPy는 완전한 동적 디스패치를 제공하는 dynamic 타입을 제공합니다.
하나의 언어, 두 개의 수준. SPy는 C, C++, Rust 등의 저수준 능력과 Python의 고수준 추상화 및 표현력을 동시에 지원합니다. 예를 들어 SPy 자신의 list와 dict 타입은 SPy로 작성되어 있습니다.
Current Status: **kwargs and dynamic
이 글을 쓰는 시점에서 **kwargs와 키워드 인자는 아직 구현되지 않았습니다. dynamic 타입은 인터프리터에서는 동작하지만, 컴파일러에서는 아직 동작하지 않습니다.
제가 이렇게 야심 찬 프로젝트를 시작하게 된 동기는 여러 가지입니다. 그중 일부는 지난 약 20년 동안 PyPy 코어 개발자로 일하며 직접 겪은 경험에서 나왔습니다. 또 일부는 수년간 실제 프로덕션 환경에서 사용되는 Python 코드를 최적화하는 일을 하면서 얻은 통찰에서 나왔습니다. 마지막으로 일부는 현실에서 Python이 실제로 어떻게 사용되는지를 관찰하면서 나온 것입니다.
이 글 전체를 관통하는 주제가 있습니다. Python 개발자들은 이미 언어의 제약된 부분집합 안에서 코드를 작성하고 있습니다. 가독성을 위해서, JIT를 위해서, 타입 체커를 위해서 그렇습니다. 하지만 이런 부분집합들은 비공식적이고 명세가 빈약합니다. SPy는 이런 제약을 공식화하고, 그 대가로 강력한 도구를 제공합니다.
PyPy 작업을 하면서 저는, 제가 목표로 하는 수준의 성능으로는 Python을 근본적으로 최적화하는 것이 불가능하다는 결론에 이르렀습니다. 언어의 몇몇 기능은 Python을 "본질적으로 느리게" 만듭니다. 저는 EuroPython 발표 Myths and fairy tales around Python performance에서 이 점을 폭넓게 이야기했습니다(video, slides, LWN write-up).
Levels of performance
서로 다른 두 언어와 구현을 비교할 때 "X는 Y보다 N배 빠르다"고 말하는 것은 큰 의미가 없습니다. 정확한 수치는 벤치마크와 하드웨어에 따라 크게 달라질 수 있기 때문입니다.
그럼에도 평균과 최선의 경우에 기대할 수 있는 속도 향상의 자릿수 정도는 적어 볼 수 있습니다.
CPython의 JIT는 CPython 인터프리터보다 10% - 50% 더 빠른 것을 목표로 합니다.
PyPy의 JIT는 CPython보다 2배 - 10배 더 빠른 것을 목표로 합니다.
SPy는 CPython보다 10배 - 100배 더 빠른 것을 목표로 합니다.
첫 번째 문제는 Python이 극도로 동적이라는 점입니다. 단지 동적 타이핑만을 말하는 것이 아닙니다. 주어진 Python 프로세스 안에서 "세계" 자체가 움직이는 표적이며, "모든 것이 언제든 바뀔 수 있다"는 사실도 포함합니다. 예를 들어 import 문은 런타임에 동적으로 해석되며, 이를 정적으로 신뢰성 있게 결정하는 것은 불가능합니다. 모듈과 클래스는 가변적입니다. 그 내용은 언제든 바뀔 수 있고, 컴파일러는 이에 대해 방어적으로 대응해야 합니다. 객체의 __class__도 바뀔 수 있습니다.
그 위에 연산 디스패치도 매우 동적입니다. ., +, [] 같은 대부분의 문법 구성은 런타임에 해석해야 하는 매우 복잡한 조회 로직을 유발합니다. 그리고 객체의 타입을 안다고 해서 그 동작을 예측하기에 충분하지도 않습니다. 클래스의 동작을 덮어쓰는 인스턴스별 속성이 있을 수 있기 때문입니다.
JIT 컴파일러는 이 두 문제를 해결할 수 있고, PyPy가 그것을 증명합니다. 하지만 JIT 컴파일 기반 접근법은 나중에 전용 섹션에서 보겠지만 그 자체의 고유한 문제를 도입합니다.
마지막으로, 제가 알기로는 JIT로도 해결할 수 없는 문제가 있습니다. Python의 의미론은 본질적으로 캐시 비우호적입니다. Python에서는 모든 것이 객체다 모든 것이 포인터이며, 객체는 기본적으로 가변적입니다. CPython에서 객체 참조는 C의 PyObject *로 구현되는데, 이는 속성 조회나 항목 조회를 할 때마다 포인터를 역참조해야 한다는 뜻입니다. 코드 한 줄을 실행하기 위해 포인터를 4개나 5개 역참조해야 하는 일도 드물지 않습니다. 이것을 Pointer Chasing이라고 하며, 간단히 말해 성능에 매우 나쁩니다™. 메모리 지역성을 파괴하기 때문입니다. 두 개의 Point를 갖는 고전적인 Rect 예를 보겠습니다.
@dataclass
class Point:
x: float
y: float
@dataclass
class Rect:
a: Point
b: Point
r = Rect(Point(1, 2), Point(2, 3))
width = abs(r.b.x - r.a.x)
height = abs(r.b.y - r.a.y)
훌륭한 PyTutor를 사용해 Rect의 메모리 배치를 단순화한 버전을 시각화할 수 있습니다.
각 화살표는 포인터이고, 화살표를 따라간다는 것은 "캐시 미스"가 발생할 가능성이 있다는 뜻입니다. 이 특정한 경우에는 4개의 float를 연속된 메모리 영역에 저장하는 편이 더 나은 메모리 배치일 것입니다. 하지만 그렇게 하면 언어가 보장하는 어떤 성질을 깨게 됩니다. 예를 들어 id(r.a) == id(r.a)라든가, r.a가 복사본을 만들지 않는다는 성질 같은 것들입니다. 따라서 표준을 준수하는 Python 구현은 그렇게 할 수 없습니다.
About CPUs, cache and RAM
현대 CPU는 매우 복잡한 존재이므로, 아래 설명은 단순화한 것입니다.
RAM에서 값을 불러오는 비용은 계산 자체의 비용에 비해 매우 큽니다. CPU 레지스터에 이미 들어 있는 두 숫자를 더하는 것은 1사이클에 할 수 있지만, 그 값을 메모리에서 가져와야 한다면 CPU는 데이터가 로드되기를 기다리며 수백 사이클 동안 놀고 있어야 합니다.
RAM에서의 로딩이 너무 느리기 때문에, CPU는 자주 사용하는 데이터를 "캐시"에 저장합니다. 캐시에서 불러오는 것은 훨씬 빠르므로, 캐시된 데이터로 작업할 때 CPU는 초당 훨씬 더 많은 명령을 실행할 수 있습니다. 보통 현대 시스템에는 세 단계의 캐시가 있습니다. L1, L2, L3입니다. L1이 가장 작고 가장 빠르며, 그다음 각 단계는 이전 단계보다 더 크고 더 느립니다. RAM이 가장 느립니다. 캐시에 들어 있는 메모리 주소를 불러오면 cache hit, 그렇지 않으면 cache miss입니다.
이 상자 안에서 설명할 수 없는 여러 이유 때문에, 주소 A가 캐시에 있다면 A에 "가까운" 값들도 함께 캐시에 들어 있습니다. 그래서 좋은 메모리 지역성은 cache hit 가능성을 높입니다. 반대로 포인터를 따라가면 메모리의 "먼" 영역에 도달할 위험이 크고, 따라서 포인터 역참조 하나하나가 잠재적인 cache miss가 됩니다.
이 video는 각 수준의 상대적 성능에 대한 시각적 직관을 줍니다. L1과 비교하면 RAM은 엄청나게 느리고, 그래서 cache miss 하나하나가 성능 면에서 재앙이 됩니다.
앞선 섹션에서 Python이 얼마나 큰 동적성을 허용하는지 보았습니다. 하지만 실제로는 그런 일이 그리 자주 일어나지 않습니다.
우리는 의존성이 고정된 매우 잘 정의된 환경에서 애플리케이션을 실행합니다. 하지만 인터프리터는 이를 모르며, import numpy가 사실은 같은 디렉터리의 같은 버전 numpy를 매번 또다시 가져온다는 사실을 실행할 때마다 다시 알아내야 합니다.
게다가 수년 동안 커뮤니티는 어떤 패턴이 "좋은지", 그리고 어떤 패턴이 가독성과 유지보수성에 해로운지를 이해하게 되었습니다. 우리는 잘 정의된 타입 위에서 동작하는 함수를 선호하고, __init__ 밖에서 속성을 만드는 것은 나쁜 관행이며, monkey-patching은 특정 맥락(예: 테스트)에서만 허용되고, 객체의 __class__는 절대 바꾸지 않는 식입니다.
사실상 우리는 이미 Python의 한 부분집합을 사용하고 있으며, 저는 그것을 RealPython이라고 부르고 싶습니다. 하지만 그것은 공식적으로 명세되지 않았고, 경우에 따라 조금씩 다른 부분집합입니다. 인터프리터는 실제로 이런 일이 벌어지는 0.1%의 경우에도 대비해야 하므로, 이 사실을 활용할 수 없습니다.
그렇다고 해서 언어에서 동적성과 메타프로그래밍을 그냥 제거할 수도 없습니다. 그것이야말로 생태계에서 가장 강력하고 풍부한 라이브러리들을 가능하게 만드는 요소이기 때문입니다.
최근 몇 년 사이 정적 타이핑과 타입 체커는 Python 커뮤니티에서 점점 더 인기를 얻고 있습니다. 분명히 해두겠습니다. 저는 제약 조건을 고려했을 때, Python의 타이핑 이야기는 충분히 괜찮고 잘 설계되어 있다고 생각합니다. 제가 더 잘할 수 있을 것 같지도 않습니다. 그럼에도 Python은 정적 타이핑을 위해 설계된 언어가 아니고, 절대적인 기준에서 보면 현재 상황은 아쉬운 점이 많습니다.
정적 타이핑 대 동적 타이핑 논쟁은 수십 년째 이어지고 있습니다. 각각의 전형적인 장단점을 살펴봅시다.
정적 타이핑의 첫 번째 전형적인 장점은 타입 체커가 프로그램에서 특정 종류의 버그가 발생할 수 없음을 증명할 수 있다는 점입니다. 여기서 증명은 수학적 의미의 증명입니다. 하지만 안타깝게도 Python에서는 그렇지 않습니다.
인터프리터는 타입 애너테이션을 그냥 무시합니다. 타입 체커는 최선을 다하지만, Python의 전체 의미론을 이해하지 못하거나, 혹은 의도적으로 무시하여 실제로 일어나는 일에 대해 잘못된 관점을 갖는 경우가 있습니다. 다음의 우스운 예시는 분명히 잘못되었고 런타임에 AttributeError를 발생시키지만, mypy는 아무 문제 없이 통과시킵니다.
class Point:
x: int
y: int
p = Point()
print(p.x)
따라서 Python 타입 체커는 실제 정리 증명기라기보다 린터에 가깝게 다루어야 합니다. 물론 없는 것보다는 낫지만, 실제로 건전한 타입 시스템이 주는 장점과는 거리가 멉니다.
정적 타이핑의 두 번째 전형적인 장점은 컴파일러가 더 효율적인 코드를 생성할 수 있다는 점입니다. 하지만 타입이 실제로 올바른지 확신할 수 없으므로, 그것을 컴파일의 지침으로 사용할 수 없습니다. mypyc 같은 프로젝트가 이 방향으로 가고 있지만, 그렇게 함으로써 호환성을 깨고 동적성을 제한합니다. 결국 다시 "Python의 부분집합/변형을 위한 컴파일러" 범주로 되돌아가는 셈입니다.
마지막으로 정적 타이핑의 또 다른 장점은 IDE와 도구가 타입 지식을 활용해 개발을 도울 수 있다는 점입니다. 저는 이것이 Python에서 실제로 큰 성공이라고 생각하고, Python 타이핑 시스템에 대한 열광의 큰 부분이 여기서 나온다고 봅니다.
반면, 동적 타이핑의 전형적인 장점은 더 많은 유연성을 허용한다는 것입니다. 바로 이것도 Python 타이핑의 또 다른 고충입니다. 제 코드를 더 좋게 만들 수 있는 패턴이 있는데도, 그것이 완전히 올바르더라도 타입 체커가 이해하지 못하는 경우를 자주 봅니다. 타입 검사 가능한 언어 부분 역시 Python의 또 다른 부분집합입니다. 이번에는 조금 더 잘 명세되어 있지만, 여전히 형식 명세와는 거리가 멉니다.
이제 제가 하려는 말이 다소 과장이고, 도발적으로 들릴 수 있다는 점은 알고 있습니다. 하지만 어떤 관점에서는, Python에서 정적 타이핑을 사용함으로써 우리는 양쪽 세계의 최악만 얻고 있는 것일 수 있습니다. 보장은 없고, 여전히 느리며, 동적 타이핑이 실제로 유용한 패턴마저 막아 버립니다.
안전하고, 빠르며, 그리고 여전히 파이써닉한 패턴을 허용하는 방식의 정적 타이핑이 있다면 더 낫지 않을까요?
"왜 Python은 느린가" 섹션에서 우리는 세 가지 문제를 나열했습니다.
가변적인 세계
동적이고 복잡한 디스패치
캐시 비우호성
PyPy JIT는 사실 (1)과 (2)를 아주 잘 해결합니다. RealPython은 Python의 부분집합이다에서 본 사실, 즉 많은 "기상천외한 일들"은 실제로는 일어나지 않거나 매우 드물게만 일어난다는 점을 활용하기 때문입니다. 핵심은 다음과 같은 조건을 추측적으로 가정하는 것입니다.
특정 코드 조각에서 변수의 타입은 안정적이다
클래스와 모듈의 __dict__는 바뀌지 않는다
객체의 __class__는 바뀌지 않는다
기타 등등
그 다음, 그 가정이 유지되는 한 매우 빠른 코드를 생성합니다. 그리고 가정이 여전히 유효한지 검사하고, 그렇지 않을 때는 디옵티마이즈하기 위한 추가 코드와 가드도 생성합니다.
이 높은 수준의 개요는 PyPy뿐 아니라 제가 아는 모든 Python JIT 컴파일러에 해당합니다. 물론 실제 저수준 세부 사항은 구현에 따라 매우 크게 달라질 수 있습니다.
이 전략의 가장 큰 단점은, 휴리스틱이 맞는 동안에만 코드가 빠르다는 점입니다. 코드 한 줄만 바꿨는데도 JIT가 더 이상 올바르게 최적화할 수 없어서 생성된 코드가 2배, 5배, 심지어 10배 느려지는 경우를 쉽게 찾을 수 있습니다. 짜증 나는 점은 그런 경우 JIT는 왜 최적화할 수 없는지 완벽하게 알고 있지만, 우리에게 말해주지 않는다는 것입니다. 그런 경우 경고를 내보내는 시도를 해볼 수는 있겠지만, JIT의 관점에서는 경고가 의미 있는 경우와 그렇지 않은 경우를 구분하기가 어렵습니다.
최대 성능을 원한다면 휴리스틱을 따르는 코드를 작성해야 합니다. 이것 역시 Python의 또 다른 부분집합이지만, 이번에는 명세가 매우 느슨하고 정확히 무엇을 할 수 있고 무엇을 할 수 없는지 알려면 JIT 내부 구조에 대한 깊은 지식이 필요한 경우가 많습니다. 이것을 JITPython이라고 부르겠습니다. 그러면 성능을 추론하고 특정 코드 조각이 빠를지 느릴지 예측하는 일이 매우 어려워집니다.
게다가 JIT에는 다른 문제들도 있습니다. 순서 없이 나열하면 다음과 같습니다.
구현이 훨씬 더 복잡합니다. 기여하기가 더 어렵고, 많은 엔지니어링 역량이 필요합니다.
아무리 진보한 JIT라도 최적화에 실패하는 경우는 항상 존재합니다.
가드와 검사에는 런타임 비용이 있습니다.
모든 것이 잘 되더라도 생성 코드의 품질은 AOT 컴파일러보다 떨어집니다. JIT는 최적화에 너무 많은 시간을 쓸 수 없기 때문입니다.
최고 성능에 도달하기 전에 워밍업 단계가 있습니다.
메모리를 더 많이 쓰는 경향이 있습니다.
특히 PyPy와 CPython 자체 JIT 같은 트레이싱 JIT의 경우, 제가 여기에서 자세히 논의한 다른 종류의 문제도 있습니다.
JIT 컴파일러에는 또 다른 문제가 있습니다. C API는 어떤 JIT에게도 완전히 불투명합니다.
Python 생태계의 거대한 부분은 컴파일 언어(C, C++, Rust, Cython, ...)로 작성되어 있고, 이들은 C API를 통해 Python 인터프리터와 통신합니다. JIT가 C 확장을 호출해야 하는 순간, 무슨 일이 벌어지고 있는지 추적을 잃고 "모든 것이 바뀌었다"고 가정해야 합니다. 이 때문에 종종 디옵티마이즈를 하거나 값비싼 정합성 검사를 수행해야 합니다.
이상적인 세상에서는 언어 경계를 넘어 전체 프로그램을 볼 수 있는 최적화기가 있었으면 합니다. 예를 들어 Python에서 호출한 C 함수를 인라인하거나 그 반대로도 할 수 있겠지요. 이것은 링크 타임 최적화(LTO)를 사용하는 AOT 컴파일 언어에서는 거의 공짜로 일어나는 일이지만, Python에서는 그저 불가능합니다.
RPython은 PyPy의 구현 세부 사항이지만, 매우 흥미로운 세부 사항입니다. "Restricted Python"의 약자이며, C로 컴파일 가능한 Python의 부분집합입니다. 그리고 PyPy 인터프리터가 바로 이 언어로 작성되어 있습니다.
PyPy : RPython = CPython : C
RPython 프로그램은 보통 수정 없이 CPython에서 실행될 수 있고, 컴파일된 버전과 같은 결과를 얻습니다. 즉, 개발과 디버깅에는 CPython 인터프리터를 사용하고, 배포에는 RPython 컴파일러를 사용할 수 있습니다. 양쪽 세계의 장점을 모두 취하는 셈입니다. 이 패턴은 PyPy 개발에 매우 많이 사용됩니다.
RPython의 또 다른 흥미로운 기능은 구현 방식에서 직접 나오는 메타프로그래밍 능력입니다. RPython 컴파일러는 Python으로 작성되어 있고, 대상 프로그램의 진입점을 먼저 CPython 안에서 import한 다음, 그 진입점이 재귀적으로 참조하는 살아 있는 함수 객체들의 바이트코드를 분석하는 방식으로 동작합니다.
흥미로운 부분은 초기 import가 전적으로 CPython 내부에서 일어난다는 점입니다. "import time"에는 RPython 프로그램이 Python의 모든 힘을 사용해 메타프로그래밍을 할 수 있습니다. 데코레이터, 메타클래스, 코드 생성 등을 모두 포함해서요. 이것이 가능한 이유는 RPython 컴파일러가 이 단계가 끝난 후에야 개입하기 때문입니다.
PyPy 내부에서 RPython은 최종 사용자에게 제공하는 "완전한 Python"을 작성할 수 있게 해 주는 도구일 뿐입니다. RPython은 애초에 최종 사용자가 쓰도록 의도된 것이 아니었기 때문에, 사용성이 매우 나쁩니다. 타입 오류가 들어 있는 RPython 프로그램을 컴파일하려 하면 컴파일러 내부의 AssertionError가 나오거나, 이해하기 어려운 오류 메시지가 나오는 일이 꽤 자주 있습니다.
그런 단점에도 불구하고, 다음의 조합은
개발과 디버깅에 인터프리터를 사용할 수 있다는 점
"컴파일 시간"의 완전한 메타프로그래밍 능력
런타임의 정적 타이핑
실제로 매우 좋고 즐겁게 사용할 수 있음이 증명되었습니다.
SPy는 여기에서 많은 영감을 받았습니다. 여러 관점에서 보면 SPy는 "RPython 2.0"으로 볼 수 있습니다. 결국 S는 "Static"을 뜻하지만, R 다음 글자이기도 하니까요 :).
SPy는 앞선 섹션들에서 설명한 모든 문제를 해결하는 것을 목표로 합니다. 이를 위해 우리가 위에서 본 여러 "Python 부분집합"의 제약을 공식화하는 한편, 제거한 기능만큼 강력하면서도 성능 지향적 컴파일에 더 적합한 새로운 기능들을 추가합니다.
이 연재의 다음 글들에서 모든 것을 아주 자세히 다루겠지만, 지금은 SPy의 주요 특성들을 힌트 수준에서 살펴보겠습니다.
SPy의 타입 시스템은 다른 목표를 염두에 두고 설계되었고, 예를 들어 mypy와 비교하면 더 제한적입니다. 그래도 의미가 있을 때는 호환되도록 노력합니다. 많은 일반적인 경우에는 최종 사용자가 눈에 띄는 차이를 전혀 느끼지 못할 것입니다.
타입은 인터프리터가 적극적으로 강제합니다. 호환되지 않는 타입의 값을 변수에 할당하려 하면 TypeError가 발생합니다. dynamic 타입을 선택적으로 사용할 수는 있지만, 더 정밀한 타입으로의 모든 할당이나 캐스트에는 런타임 검사가 삽입됩니다.
타입 시스템은 건전하며, 프로그램이 타입 체커를 통과하면 런타임에 TypeError가 없다는 것이 보장됩니다. 컴파일러는 이 지식을 활용해 더 효율적인 코드를 생성할 수 있습니다. 또한 인터프리터와 컴파일러가 정확히 동일한 출력을 만든다는 것도 보장됩니다.
이것만으로도 Python의 정적 타이핑에 비해 개선입니다. 이제 프로그램에 타입 오류가 없다는 것이 보장되고, 훨씬 더 빨라지기 때문입니다. 하지만 SPy가 오직 정적 타입 시스템만 갖고 있다면, 다른 모든 "Python 컴파일러"와 크게 다르지 않았을 것입니다. 차이를 만드는 것은 메타프로그래밍과 다른 "파이써닉한" 패턴을 타입 안전한 방식으로 가능하게 하는 기능들입니다.
프로그램을 실행하기 전에 SPy는 소스 코드를 분석하고 import될 모듈 집합을 정적으로 결정합니다.
그 후 우리가 import time이라고 부르는 단계에 들어가서 필요한 모든 모듈을 import합니다. 데코레이터, 메타클래스, 모듈 수준 초기화 같은 것들은 이 단계에서 실행되며, 세계는 "평소처럼 가변적"입니다.
그 다음 우리는 세계를 동결합니다. 모든 전역 상수는 동결되어 불변이 되며, 모듈과 클래스도 여기에 포함됩니다.
마지막으로 runtime에서 프로그램은 불변의 세계 안에서 "평소처럼" 실행됩니다.
이것은 분명히 RPython이 하는 일과 비슷합니다. 큰 차이는 RPython은 "Import time" 인터프리터로 CPython을 사용하는 반면, SPy는 자신의 인터프리터를 사용한다는 점입니다. 많은 Python 메타프로그래밍 패턴이 이 구조에 아주 잘 들어맞고, RPython에 대한 PyPy 팀의 경험이 이 주장을 뒷받침합니다.
이것은 기본적으로 RealPython과 JITPython의 몇 가지 규칙을 공식화한 것입니다. 큰 장점은 규칙을 어기면 미묘한 성능 저하 대신 매우 명확한 오류 메시지를 얻는다는 점입니다.
SPy의 또 다른 근본 개념은 redshifting입니다.
각 표현식에는 색이 주어집니다.
blue 표현식은 부작용이 없고 모든 피연산자가 정적으로 알려져 있으므로 미리 안전하게 평가할 수 있는 것들입니다.
red 표현식은 runtime에 평가해야 하는 것들입니다.
redshifting 동안 우리는 코드의 모든 blue 부분을 적극적으로 평가합니다. 이것은 부분 평가의 한 형태입니다. 이 과정은 앞서 논의한 동결과 아주 잘 어울립니다. 동결된 데이터에 대한 많은 연산이 자동으로 blue가 되기 때문입니다. 예를 들어 객체의 타입을 정적으로 안다면, 동결된 클래스 계층 안에서 메서드를 조회하는 로직은 blue 연산이 되고 최적화로 사라지며, 결과로 직접 호출만 남습니다.
지금까지는 이것이 보통의 상수 폴딩과 다르지 않아 보일 수 있습니다. 다만 여기서는 그것이 반드시 일어난다는 차이가 있습니다. 더 강력해지는 지점은 일부 함수를 @blue로 표시할 수 있다는 능력입니다.
@blue 함수를 호출하는 것은 언제나 blue 연산이며, 함수 본문은 redshifting 중에 실행됩니다. 이것은 어떤 면에서는 C++ 템플릿으로 하는 일과 비슷하지만, 중요한 차이는 메타프로그래밍에 사용하는 언어가 runtime에 사용하는 언어와 정확히 같다는 점입니다. 게다가 @blue 함수는 익숙한 SPy 인터프리터에 의해 실행되므로, 예를 들어 breakpoint()를 사용해 훨씬 더 쉽게 디버깅할 수 있습니다.
제네릭은 타입을 대상으로 작동하는 @blue 함수의 특수한 경우일 뿐입니다. MyList[T] 구문은 사실 다음의 문법 설탕입니다.
@blue
def MyList(T):
class _MyList:
items: array[T] # fictional example
...
return _MyList
Current status: generics
Type[T] 문법 설탕은 아직 구현되지 않았지만, @blue 함수로 제네릭 타입을 작성하는 것은 완전히 동작하며, SPy가 자신의 list, dict, array 타입을 구현하는 방식이기도 합니다.
Zig comptime
SPy의 @blue 함수는 Zig의 comptime 기능과 매우 많은 공통점을 가집니다.
처음 SPy를 설계할 때 저는 Zig를 몰랐습니다. 정말입니다! 하지만 @blue 코드에 대한 초기 아이디어를 보여준 뒤 누군가 Zig를 알려 주었습니다. 아주 다른 맥락에서 이미 구현된 것을 보고 기분 좋게 놀랐습니다. 제 아이디어가 말이 된다는 중요한 검증이었기 때문입니다.
아주 최근에는 Zig의 창시자이자 BDFL인 Andrew Kelly를 만나는 기쁨도 있었습니다. 우리는 두 시스템의 세부 사항을 논의했고, 약간의 차이를 제외하면 기본적으로 동등하다는 데 동의했습니다.
Python에서 a + b를 수행하면, 인터프리터는 어떤 메서드를 호출할지 결정하기 위해 런타임에 복잡한 로직을 실행해야 합니다. SPy에서는 거의 같은 로직을, 다만 컴파일 시간에 수행합니다. 연산자는 두 단계 메커니즘으로 구현됩니다.
먼저, 컴파일 시간에 이용 가능한 정보를 조사해 구현을 조회합니다. 특히 피연산자의 정적 타입을 봅니다.
그런 다음, 1단계에서 얻은 구현을 호출합니다.
요령은 1단계가 전적으로 blue이며, redshifter에 의해 완전히 최적화되어 사라진다는 점입니다. 예를 들어 다음 코드를 보겠습니다.
def foo(x: float, y: float) -> float:
return x + y
redshifting 후에는 이렇게 됩니다.
def foo(x: float, y: float) -> float:
return `operator::f64_add(x, y)`
이것은 Python 의미론에서 크게 벗어나는 지점입니다. 우리는 runtime의 실제 타입이 아니라 피연산자의 정적 타입을 기준으로 동작하기 때문입니다. 저는 이것이 대다수 사용 사례를 포괄한다고 믿습니다. 정말로 완전한 동적 디스패치가 필요한 경우에는 dynamic 타입을 사용해 선택적으로 켤 수 있습니다.
사용자 정의 타입도 여전히 __add__ 등을 오버라이드하고 이 "blue time" 조회 로직에 참여할 수 있습니다. 자세한 내용은 다음 글에서 설명하겠습니다.
Python의 동적인 성격과 표현력은 Python이 큰 인기를 얻게 된 이유의 중요한 부분입니다. 이것 덕분에 고급 사용자들은 우리가 사랑하는, 직관적이고 고수준 API를 가진 놀라운 라이브러리들을 만들어 낼 수 있었습니다. 하지만 그런 표현력에는 성능, 타입 안전성 등 여러 측면의 문제가 따릅니다.
SPy는 동적성을 성능을 해치지 않는 잘 정의된 위치들로 제한함으로써 이런 문제를 해결하려고 합니다.
이 연재의 다음 글들에서는 이것이 실제로 어떻게 동작하는지 깊이 있게 들어갈 것입니다. 타입 시스템, blue/red 평가 모델, 정적 디스패치, 그리고 인터프리터와 컴파일러의 구현을 다룰 예정입니다. SPy 코드의 구체적인 예를 보고, 제로 코스트 추상화 같은 기능이 실제로 어떻게 달성되는지도 살펴볼 것입니다.
직접 SPy를 탐험해 보고 싶으신가요? 코드와 예제를 보고 프로젝트의 개발을 따라가려면 GitHub의 SPy 저장소를 방문하세요. 질문이 있거나, 설계 결정에 대해 토론하고 싶거나, 기여에 관심이 있다면 SPy Discord server에 참여해 주세요. SPy는 아직 개발 초기 단계이며, 지금이야말로 참여해서 그 미래를 함께 만들어 가기에 좋은 시기입니다.