Rust 컴파일러, 두 달 만에 평균 4.57% 빨라져 (629개 벤치마크 중 555개 개선)

증분 컴파일이 계속 쉬운 것만 먹고 있는 느낌임. 남은 컴파일 시간이 작년이랑 같은 자리에 있는지가 진짜 궁금한 부분이고.

EverInitializedPlaces 예시가 제일 인상적임. CFG 순회만 바꿔서 apply_effects_in_block 호출이 150만에서 9만으로 줄었다는 거잖아. 큰 최적화는 뜨거운 루프를 만지는 게 아니라 알고리즘을 바꾸는 데서 나오는 거고, 629개 벤치마크에서 두 달 만에 평균 4.57%면 놀라운 수치임.

그건 컴파일러만 그런 게 아니라 거의 모든 최적화에 해당하는 말 아닌가. 내가 쓰는 순서도 안 해도 되는 일 찾기, 자료구조 다시 보기, 그다음 알고리즘인데. 컴파일러는 한 번도 안 써봤지만 잘 먹히더라.

근데 왜 처음부터 느린 거임? Rust는 하나도 모르는데 C 컴파일러랑 비교하면 얼마나 느리고, 성능을 잡아먹는 범인은 뭐임?

C++ 컴파일러랑 비슷함. 한 가지 이유가 있는 게 아니라 언어가 크고, 최적화를 많이 하고, 안전성 검사에 LLVM까지 느리고, 제네릭이 코드를 더 찍어내는 것도 있고.

다른 언어는 컴파일할 때 안 하는 정적 분석을 컴파일 타임에 돌리는 거임.

애초에 빨라진다는 기사가 컴파일러가 느리다는 뜻은 아님. rustc가 clang보다 느린 건 맞는데 대충 1~5배 정도고 뭘 컴파일하느냐에 따라 다름. 단형화에 트레이트 해석, 타입 추론, borrow checker까지 하니까 C보다 할 일이 훨씬 많음.

일을 하면 공짜가 아님. Go가 빠른 것도 최신 언어치고 하는 일이 적어서인 게 큼. 검사와 보장을 잔뜩 넣으면 파레토 경계에서 느려질 수밖에 없고, Rust의 결함이라기보다는 그냥 그런 거임.

제로 코스트 추상화가 컴파일 시간까지 제로는 아님. 고수준 추상화는 컴파일러가 걷어내야 할 보일러플레이트로 바뀌고, 최적화 없는 빌드에서는 링커가 병목인 경우도 많음. 오브젝트 포맷이 옛날에 설계돼서 증분이나 병렬 링크가 어렵고.

대기업들이 오픈소스 메인테이너한테 하는 후원이 Rust 경험에 측정 가능한 차이를 만들고 있는 게 반가움. 직원들이 컴파일 기다리는 시간이 5% 줄었다고 알려주면 Nick 같은 사람한테 투자가 더 들어갈 텐데.

borrow checker를 더 똑똑하게 만들면서도 5% 빨라진 게 제일 좋음. 예전엔 거부하던 코드를 이제 통과시켜 주는데 속도까지 챙겼으니 케이크도 먹고 케이크도 가지는 셈임.