"컴파일러가 사람보다 낫다?" LuaJIT 개발자가 밝히는 인터프리터 튜닝의 진실

요약 "요즘 컴파일러가 워낙 똑똑해서 사람이 직접 어셈블리로 짜봤자 못 이긴다"는 말이 정설처럼 통하지만, 전설적인 LuaJIT의 개발자 마이크 폴(Mike Pall)은 인터프리터 메인 루프 영역만큼은 전혀 그렇지 않다고 단언했습니다. 그가 설명한 바에 따르면 일반적인 C 언어로 작성된 스위치문 기반 인터프리터는 수십 개의 명령어와 수백 개의 느린 분기 경로(slow paths)를 포함합니다. 이러한 다이아몬드형 및 중첩 다이아몬드형 제어 흐름은 컴파일러의 최적화와 레지스터 할당 관점에서 최악의 시나리오로 꼽힙니다. 컴파일러 입장에서는 무엇이 빠른 경로(fast path)이고 무엇이 느린 경로인지 구분할 힌트가 부족하며, 거대한 단일 제어 흐름 그래프 안에서 모든 코드가 서로 영향을 줄 수 있어 최적화나 코드 호이스팅 기회가 전부 날아가 버립니다. GCC의 확장 문법인 'computed goto'를 써서 직접 스레디드(direct-threaded) 방식으로 루프를 풀어도 한계는 명확합니다. goto 문이 코드 어디로든 튈 수 있어 컴파일러가 루프 패턴을 인식하지 못하고, 레지스터 할당기가 각 구간을 따로 처리하느라 일관된 레지스터 배치가 불가능해집니다. 반면 어셈블리로 직접 작성할 경우 모든 명령어에 걸쳐 고정된 레지스터 배치를 유지할 수 있고, 빠른 경로에서는 모든 변수를 레지스터에 상주시키며 느린 경로에서만 스필(spill/reload) 처리를 할 수 있습니다. 또한 느린 경로 코드를 다른 메모리 영역으로 빼서 인스트럭션 캐시(I-Cache) 효율을 극대화하고 명령어 선행 로드와 디코딩을 기계어 수준에서 최적화할 수 있습니다. 마이크 폴은 현대 컴파일러가 어디까지나 '평균적인 코드'에 맞춰 조율된 휴리스틱 덩어리이기 때문에, 인터프리터 루프처럼 극한의 최적화가 필요한 특수 영역에서는 여전히 사람이 직접 손으로 깎아 만든 어셈블리를 당해낼 수 없다고 결론지었습니다.