PyPy

2007년에 처음 발표된 Python의 언어 구현 중 하나로, C로 짜인 기존의 CPython과 달리 Python으로 Python을 만드는 프로젝트이다.[1] 여기만 보면 뭔가 이상한 짓 하는 프로젝트 내지 실험적인 프로젝트처럼 느껴지겠지만, 이 프로젝트의 진짜 놀라운 점은 기존 CPython보다 전혀 느리지 않을 뿐더러, 오히려 성능면에서 CPython을 능가하고 있다는 점이다. 나아가 이 링크에서 보이는 대로, 계속해서 빨라지고 있다! 표준 구현인 CPython과의 속도비교. PyPy를 개발하면서 지속적으로 업데이트 하고 있다.

PyPy는 단순히 Python을 가지고 장난을 하려고 시작한 프로젝트가 아니다. Psyco라고 하는, 기존 파이썬 위에다가 Just-In-Time 컴파일을 구현해서 실행성능을 높히는 프로젝트가 있었는데, 이걸 개발하던 Armin Rigo라는 사람이 아예 JIT 컴파일을 하는 파이썬을 처음부터 다시 구현하기로 생각했다. 그래서 2003년부터 PyPy 개발을 시작하여 유럽연합의 연구자금 지원을 받아가며 지금도 개발하고 있다.

인터프리터 방식의 Python을 가지고 파이썬으로 돌리는 파이썬을 어떻게 만들었을까. PyPy의 접근법은 이렇다.

뭔가 속는 느낌이지만 처음 한번만 기존 파이썬의 도움을 받으면 그 다음부터는 스스로 만든 구현으로 저 과정을 자체적으로 계속 반복할 수 있다. 이러한 이유로 로고가 우로보로스인 셈. 이게 얼핏 보면 '닭이 먼저냐 달걀이 먼저냐' 같은 것으로 착각할 수도 있지만, 이런 식의 접근법은 실제로 프로그래밍 언어를 제작할 때 해당되는 사항이며[4], 더 좋은 장비의 개발을 위해 기존의 장비를 사용하는 것과 다름이 없다. 짱돌로 뗀석기를 만들고, 뗀석기로 간석기를 만들었던 것 처럼 인류 역사에 고고히 전해져오는 방법론 중 하나이므로 속는 느낌을 가질 필요는 전혀 없다.

이런 식으로 어떤 언어로 자기 자신을 구현하는 것을 부트스트래핑(Bootstrapping) 또는 부팅(Booting)[5]이라고 하는데, 이렇게 하는 이유는 처음부터 작업하는 것보다 생산성이 좋기 때문이다. 처음부터 어셈블리어로 작업하면 이론상 최강의 성능을 발휘할 수는 있으나 그 가능성은 매우 낮고 생산성도 최악이다.(최적화가 그래서 힘들다.) 이 때문에 대부분의 프로그래밍 언어도 초창기에는 어셈블리어나 다른 고급언어의 도움을 받지만, 일정 단계를 넘어서면서 발전에 한계가 오면 스스로의 컴파일러/인터프리터를 제작하게 된다. Haskell 컴파일러인 GHC와 C/C++ 컴파일러인 GCC가 대표적인 예. 물론 생산성에 중점을 두기 때문에 성능이 눈에 띄게 빨라지는 일은 드물고, 단지 우연한 발견 등 여러 이유로 성능이 향상되는 것 뿐이다. PyPy의 경우 Python의 한계를 극복하기 위해 정적인 컴파일이 가능한 RPython을 따로 만들었고 뒤에도 후술한 것처럼 성능 향상을 위해 7년이라는 긴 세월을 소모했는데, 이것도 어셈블리어로 처음부터 개발하는 것보다는 짧은 것이다.[6]

PyPy는 RPython으로 이루어진 Python 인터프리터와 (역시 RPython으로 이루어진) C, .Net, JVM 등을 타게팅한 해석 툴체인으로 이루어져 있는데, 해석 툴체인은 해당 플랫폼을 위한 효율적인 코드를 생성하는 데 초점이 맞춰져 있으며, Tracing JIT을 통해 인터프리터 단위의 JIT 컴파일이 가능하므로, CPython보다 빠른 결과물이 나오게 된다.

여기까지만이어도 그냥 기존 구현보다 그다지 느리지 않은 파이썬 구현을 다른 언어의 도움 없이 파이썬 스스로 만든 셈이지만, 여기서 하나가 더 들어간다. Armin Rigo가 뭐 만들던 사람이라는 내용이 위에도 있지만 PyPy는 JIT compiler이다. 그것도 그냥 JIT가 아니라 Meta tracing JIT라는 괴랄한 것을 구현했는데, JIT이 필요한 부분에 약간의 힌트 코드를 넣으면 RPython 해석기가 알아서 JIT compile이 되는 언어 구현을 만들어준다. 다른 언어 구현들이 JIT 좀 해보자고 무지막지한 삽질을 하는 것과 달리[7] 거의 공짜와 다름없다.

하지만, 사실 만들고 나서 보니 그렇게 보이는 거고 PyPy는 그냥 JIT를 구현한 게 아니라 JIT 구현을 만들어주는 컴파일러를 구현한 셈이 되므로 실제 작업은 훨씬 더 어려웠을 것이다. 당장 PyPy가 CPython보다 빨라진 게 PyPy 1.3부터인데, 그게 2010년 중순이다.[8] 다시 말해, 7년 동안 아무도 알아주지 않던 '진화'가 드디어 빛을 본 셈. 그리고 본인들도 "우리는 영웅이 아니며, 단지 인내심이 많았을 뿐이다."라고 말하고 있다. 잠시 PyPy 개발팀의 근성에 경의를 표하자.

여담으로, 이 녀석의 해석은 사람만 힘드는 게 아니라 컴퓨터도 힘드는 모양이다. 써볼 사람들은 시간이 남아돌고 사용하는 컴퓨터가 어지간히 고사양이 아니라면 미리 컴파일된 것을 받아 사용하자. CPython을 통한 Bootstrapping에 엄청난 시간과 메모리를 요구한다 준비물이 모두 갖춰진 상태에서 PyPy 2.2.1 달랑 하나를 빌드하는 데에 모질라 파이어폭스와 그것이 의존하는 모든 다른 패키지들을 빌드하는 것보다 시간이 더 걸린다! Core i7 3.33GHz, 다른 작업 방해 없이 코어 1개 풀사용, 8GB 램 기준으로 최소 3시간은 각오해야 한다. 64비트 CPython으로 컴파일하다 보면 Python 프로세스 하나가 램을 5GB 가까이 처묵처묵하는 것도 볼 수 있다.

그래도 이런 구조로 만든 덕분에 보너스로, RPython 컴파일을 할 때 목적 타겟을 다르게 주면 다른 플랫폼으로도 돌아가는 파이썬 구현이 나오고, 똑같은 PyPy 소스코드로 CPython 같은 것도 나오며, Jython 같은 것도, IronPython 같은 것도 나온다. 추가로 코루틴을 쓰는 Stackless Python 같은 것도 비슷한 방법으로 만들 수 있어서 Stackless Python 개발하던 Christian Tismer가 아예 PyPy 개발팀에서 같이 일하고 있다.[9]

PyPy 개발팀의 호환성 기준은 매우 심플해서, 이유 여하를 막론하고 CPython에서 되는 게 PyPy에서 안 되면 그냥 PyPy 버그다. C 확장모듈 쓴 코드 빼고는 거의 돌아간다고 보면 된다. Python 3는 갈길이 멀다. 추가할 기능에 코루틴이 있는 건 덤.

PyPy는 구조적 문제로 인해서 64비트 윈도우용으로 컴파일 할 수 없다. 32비트용으로는 제공되므로 윈도우와의 호환성에 큰 문제가 되지는 않는다. #

현재 PyPy 사이트에서 Python 3.x와의 호환성과 NumPy 지원을 위한 기부를 받고 있다.

NumPy는 속도 문제 때문에 C 확장을 쓴 대표적인 파이썬 라이브러리이자, 과학계산 분야에서 쓰이는 파이썬 코드에서 절대적인 영향을 가진 라이브러리이다. 하지만 PyPy는 때때로 C로 짠 코드보다도 빨라지기 때문에 PyPy 측에서는 아예 NumPy를 순수 파이썬 코드로 재작성할 계획을 가지고 있다.

NumPy 쪽은 이미 대부분 사용에 지장이 없는 수준까지 구현했다고. #[10]

몬티 홀 문제로 테스트 해 보자.

import random
def populate_doors(): # put a car behind one door
	door=['goat', 'goat', 'goat']
	door[random.randint(0,2)]='car'
	return door
wins = 0
losses = 0
# playing the game 100,000 times:
for x in range(100000):
	doors=populate_doors()
	first_choice=random.randint(0,2) # choose a random door
	for y in range(3): # reveal first losing, unchosen door
		if doors[y] != 'car' and y != first_choice:
			doors[y] = 'out'
			break
	if doors[first_choice] == 'car':
		losses = losses + 1 # contestant switched to losing door
	else:
		wins = wins + 1 # contestant switched to winning door
print ("All choices were switched.")
print ("Wins:"), wins
print ("Losses:"), losses

코드 출처: http://www.danielveazey.com/tag/monty-hall-problem/

PyPy가 약 25배[11] 빠르다. 물론 코드에 따라 배율에 차이가 있고 가끔씩 더 느린 코드도 있지만 어지간한 경우엔 PyPy쪽이 빠르다.