Zig Builds Are Getting Faster

Mitchell Hashimoto

Zig 빌드가 빨라지고 있다

원문은 Mitchell Hashimoto님이 에 게재했습니다. 이 블로그 구독하기

앤드루 켈리는 관점에 따라 유명하게도, 혹은 악명 높게도 “컴파일러가 너무 느려서 버그가 생기는 것이다”라고 말한 바 있다.1

그 결과, 수년 동안 Zig의 주요 공식 목표 중 하나는 더 빠른 컴파일 시간이었다. Zig 팀은 이를 현실로 만들기 위해 극도로 어려운 문제들에 매달려 왔다(예를 들어 LLVM 걷어내기, 자체 코드 생성 백엔드를 작성하고, 자체 링커를 만들고, 전반적으로 증분 컴파일을 향해 나아가는 일 등).2

수년에 걸친 이 노력의 결실이 마침내 Zig 0.15.1에서 나타나기 시작했다. Ghostty 프로젝트는 최근 Zig 0.15.1로의 업그레이드를 완료했고, 실제 빌드 시간을 공유하고자 한다.3


빌드 스크립트 컴파일

  • Zig 0.14: 7sec 167ms
  • Zig 0.15: 1sec 702ms

build.zig 스크립트 자체를 빌드하는 데 걸리는 시간이다. 위 시간은 zig build --help를 실행해 측정한 것이다.

잘 작성된 빌드 스크립트라면 스스로를 다시 빌드하는 일은 드물어야 한다. 하지만 이는 캐시되지 않은 소스로 새로 빌드할 때마다 치러야 하는 비용이다(예를 들어 프로젝트를 내려받아 소스에서 한 번 빌드하는 사용자). 따라서 사용 가능한 바이너리를 빌드하는 시간에 직접적인 영향을 미친다.


캐시 없는 Ghostty 바이너리 전체 빌드

  • Zig 0.14: 41sec
  • Zig 0.15: 32sec

여기에는 빌드 스크립트 자체를 빌드하는 시간도 포함된다. 앞선 결과를 감안하면 Zig 0.15는 그 외 나머지 부분을 약 2초 더 빠르게 빌드하고 있다. 하지만 전체 소요 시간(wall time)에서도 이 초기 빌드 시간의 변화를 확인할 수 있다.

중요: 이 빌드의 대부분은 여전히 LLVM을 사용하고 있다. Ghostty는 아직 셀프 호스티드 x86_64 백엔드로 완전히 빌드하고 링크할 수 없는데, 백엔드에 아직 버그가 있기 때문이다. 따라서 이는 LLVM이 포함된 상태에서도 Zig 컴파일러 자체의 전반적인 개선을 보여줄 뿐이다.

Ghostty가 셀프 호스티드 x86_64 백엔드를 완전히 사용할 수 있게 되면, 이 시간은 25초 이하로 급감할 것으로 예상한다. Zig 0.14에서 걸리던 시간의 절반 수준이다.


증분 빌드 (Ghostty 실행 파일)

  • Zig 0.14: 19sec
  • Zig 0.15: 16sec

가장 핵심적인 터미널 에뮬레이션 코드에 한 줄을 변경한 뒤(이스케이프 시퀀스 파서에 로그 함수 호출을 한 줄 추가) Ghostty를 다시 빌드하는 데 걸리는 시간이다.

이 빌드는 빌드 스크립트와 의존성 그래프가 완전히 캐시된 상태이므로 필요한 부분만 다시 빌드한다. Zig의 증분 컴파일은 아직 제대로 동작하지 않기 때문에 여전히 상당한 양의 코드를 다시 컴파일한다. 또한 앞선 경우와 마찬가지로 이 역시 여전히 LLVM을 사용하고 있다. LLVM을 제외하는 것만으로 이 시간은 12초 정도로 줄어들 것으로 예상한다(LLVM이 코드를 생성하는 데 걸리는 시간만큼 줄어드는 셈이다).

더 나아가 Zig가 증분 컴파일을 지원하게 되면, 이런 종류의 증분 빌드는 아무리 느려도 밀리초 단위로 측정할 수 있게 될 것으로 기대한다. 하지만 그게 현실이 될 때까지는 좀 더 지켜보자.


증분 빌드 (libghostty-vt)

  • Zig 0.14: 2sec 884ms
  • Zig 0.15: 975ms

한 줄을 변경한 뒤 libghostty-vt만 다시 빌드하는 데 걸리는 시간이다. Ghostty 실행 파일과 달리 libghostty-vt는 셀프 호스티드 x86_64 백엔드에서 완전히 동작하므로, 이는 LLVM이 빠진 상태에서의 빌드 시간 차이를 보여준다.

Ghostty 실행 파일의 경우와 마찬가지로, 증분 컴파일이 아직 완전히 동작하지 않기 때문에 libghostty-vt용 Zig 모듈 전체를 다시 빌드하고 있다. 증분 컴파일이 현실이 되면 이 역시 아무리 느려도 한 자릿수 밀리초로 떨어질 것으로 예상한다.

하지만 그럼에도, 결코 간단하지 않은 라이브러리의 빌드 시간이 1초 미만이라는 것은 놀랍다. 이 라이브러리는 현재 내가 가장 많은 시간을 들여 작업하고 있는 라이브러리인데, Zig 0.15.1로 업그레이드한 지 불과 며칠 만에 워크플로에서 엄청난 차이를 체감했다. 이전에는 빌드나 테스트 사이에 잠시 다른 탭으로 이동해 이메일을 읽곤 했지만, 이제는 너무 빨라져서 터미널 안에서 흐름을 유지한 채 계속 작업할 수 있다.

이 개선이야말로 단기간에 다가올 변화를 가장 잘 보여주는 사례다. 셀프 호스티드 x86_64 백엔드는 이미 모든 디버그 빌드를 기본으로 빌드할 수 있을 만큼 안정적이고, aarch64 백엔드도 그 수준에 가까워지고 있다. 아직 Ghostty 실행 파일 전체를 빌드할 수는 없지만, 몇 달 안에 이 문제도 해결될 것이라 확신한다.


더 빠른 빌드가 왔다

보다시피 Zig 0.15.1로 Ghostty를 빌드하는 것은 모든 시나리오에서 더 빠르다. 그것도 Ghostty의 상당 부분이 아직 셀프 호스티드 백엔드를 활용하지 못하는데도, 그리고 증분 컴파일이 아직 제대로 동작하지 않는데도 말이다!

Ghostty에 Zig를 선택한 것은 정말 잘한 결정이었다고 생각하며, Zig 팀이 컴파일 시간에 집중하고 있다는 점이 마음에 든다. 이러한 개선은 실제로 이뤄졌고, 지금 바로 체감할 수 있다. 그리고 앞으로 몇 년 안에 오늘 게시한 이 결과조차도 엄청나게 느리게 느껴질 것이라 생각한다. 😜

각주

  1. 타임스탬프 링크: https://youtu.be/5eL_LcxwwHg?t=565

  2. 이는 Zig 컴파일러의 모든 측면을 더 빠르고 더 병렬화 가능하게 만들기 위해 들어간 천문학적인 양의 작업을 생략한 것이다.

  3. 모든 측정은 동일한 x86_64 Linux 머신에서 수행되었다.

이 글은 muse-spark-1.2-contributor 모델을 사용해 번역했습니다.

댓글