메타데이터를 일찍 출력하면 Rust 빌드와 검사가 최대 두 배 빨라짐

비슷한 처리가 이미 이뤄지는 줄 알았는데, 좀 더 뒤 단계였을 수도 있겠음.
관련해서 떠오른 아이디어인데, rustc가 제네릭 메서드를 직접 인스턴스화하지 않고 필요한 항목(std::Vec::push)을 기록하면 어떨까? 별도 빌드 프로세스가 이를 받아 처리하되, 전체 빌드에서 이미 만든 항목은 다시 만들지 않도록 하는 방식임.
실제로 중복이 얼마나 생기는지는 모르지만, 중복도 문제의 일부라는 인상을 받았음. 컴파일러 엔지니어는 아니라서 크레이트별 빌드 프로필 같은 복잡한 사정이 있을 거라고 생각함.

이미 비슷하게 동작함. Cargo는 크레이트를 빌드할 때 모든 의존성의 컴파일이 끝날 때까지 기다리는 대신, 각 의존성의 메타데이터가 생성될 때까지만 기다리면 됨.
이번 시제품은 그 기반 위에서 타입 검사를 끝내기 전에 메타데이터를 기록하도록 앞당긴 것임. 실질적인 병렬성을 높일 수 있지만, 특정 크레이트 의존성 그래프에서 효과가 있을지는 컴파일 중 코어가 이미 충분히 활용되는지, 아니면 Cargo가 메타데이터를 기다리느라 코어를 놀리고 있는지에 달려 있음.

이 기법이 정식 컴파일러에 반영될 길이 있을지 기대됨.

현재 컴파일러 팀과 이야기하고 있음! 이번 변경 자체는 LLM으로 작성했고 전체 설계를 거의 검토하지 않아 그대로 반영되지는 않을 것임. 다만 언젠가 비슷한 기능이 들어가기를 바람.

Rust Zulip에 쓴 내용을 옮기면, 함수의 외부 부분인 인자와 반환값의 타입 검사 결과를 담은 .early-rmeta 파일을 생성하고, 이를 활용할 수 있는 다른 크레이트에 전달해 작업을 먼저 시작하게 함. rustc의 -Zearly-metadata 플래그로 활성화하며, 나중에 실제 메타데이터가 도착하면 먼저 쓰던 임시 메타데이터를 교체하는 기능도 필요했음.
rustc는 특정 지점에서 중단하고 재개할 수 있어야 하고, Cargo도 이를 감지하고 대응해야 함. Cargo의 -Zheadstart가 그 역할을 하며, 이를 위해 job_queue도 일부 수정됨. 직접 확인하지는 않았지만, 프로세스를 종료하지 않고 대기시키되 기존과 달리 작업 슬롯은 점유하지 않게 하는 것으로 이해함.
즉, 캐시가 아니라 작업을 멈추고 시작할 수 있게 해서 가용 슬롯을 더 잘 활용하는 방식임.

CPU의 파이프라이닝처럼 빌드 단위의 파이프라이닝을 더 깊게 적용하는 것임. Rust에는 이미 한동안 파이프라인 빌드가 있었고, 이번에는 이를 더 확장함.

내가 이해하기로는 함수의 외부 API를 신뢰하고 후속 작업을 병렬로 진행하는 쪽에 가까움. 이후 함수 본문의 타입 검사가 실패하면 컴파일을 중단할 수 있고, 그때는 불필요한 작업을 한 셈이지만 그런 경우는 꽤 드문 것으로 알고 있음.

별개로, 저장소를 커밋된 패치 파일 묶음으로 만드는 건 불필요해 보임. Git이 이미 버전 관리를 하는데, 버전 관리 안에서 또 버전 관리를 할 필요는 없음.