▲

GN⁺: 나이틀리 버전에서 병렬 프론트엔드를 통한 Rust의 빠른 컴파일 속도

 (blog.rust-lang.org)
2P by neo 6달전 | favorite | 댓글 1개

Rust 컴파일러의 병렬 프론트엔드로 빠른 컴파일 가능

  • Rust 컴파일러의 프론트엔드가 병렬 실행을 사용하여 컴파일 시간을 크게 줄일 수 있음.
  • 병렬 프론트엔드는 실험적 기능으로, -Z threads=8 옵션을 사용하여 나이틀리 컴파일러에서 시도할 수 있음.
  • 2024년에 안정적인 컴파일러로 출시될 예정임.

컴파일 시간과 병렬성

  • Rust 컴파일 시간은 지속적인 관심사이며, 컴파일러 성능 작업 그룹은 여러 해 동안 컴파일러 성능을 지속적으로 개선했음.
  • 2023년 첫 10개월 동안 컴파일 시간은 평균 13%, 메모리 사용량은 15%, 바이너리 크기는 7% 감소함.
  • 컴파일러는 이미 많이 최적화되어 새로운 개선 사항을 찾기 어려워졌으며, 병렬성이 크지만 어려운 개선 사항으로 남아 있음.

기존의 프로세스 간 병렬성

  • Rust 프로그램을 컴파일할 때 Cargo는 여러 rustc 프로세스를 병렬로 실행하여 여러 크레이트를 컴파일함.
  • 크레이트 간 의존성이 적을 때 병렬 실행이 잘 이루어지지만, 의존성이 증가함에 따라 병렬 실행이 감소함.

기존의 프로세스 내 병렬성: 백엔드

  • 컴파일러는 프론트엔드와 백엔드로 나뉘며, 백엔드는 코드 생성을 담당하고 LLVM이 이를 병렬로 처리함.
  • 프론트엔드는 파싱, 타입 체킹 등을 수행하지만, 이번 주까지 병렬 실행을 사용하지 못했음.

새로운 프로세스 내 병렬성: 프론트엔드

  • 프론트엔드는 이제 Rayon을 사용하여 미세한 병렬성으로 컴파일 작업을 수행할 수 있게 됨.
  • 병렬 프론트엔드가 활성화되고 8개의 스레드를 사용하도록 설정되면, 프론트엔드 실행 시간이 크게 줄어듦을 확인할 수 있음.

전체적인 결합

  • Rust 컴파일은 Cargo를 통한 프로세스 간 병렬성과 백엔드의 프로세스 내 병렬성의 혜택을 오랫동안 받아왔으며, 이제 프론트엔드에서도 프로세스 내 병렬성의 혜택을 받을 수 있음.
  • 컴파일러는 jobserver 프로토콜을 사용하여 생성되는 스레드 수를 제한하여 코어 수를 초과하지 않음.

사용 방법

  • 나이틀리 컴파일러는 병렬 프론트엔드를 활성화하여 출시되었지만, 기본적으로 단일 스레드 모드에서 실행됨.
  • 사용자는 -Z threads 옵션을 사용하여 다중 스레드 모드로 전환할 수 있음.

성능 영향

  • 단일 스레드 모드에서 병렬 프론트엔드를 실행하면 컴파일 시간이 기존 대비 0%에서 2% 느려질 수 있음.
  • 다중 스레드 모드에서는 컴파일 시간이 최대 50%까지 줄어들 수 있으나, 효과는 코드의 특성과 빌드 구성에 따라 다양함.

정확성

  • 단일 스레드 모드에서는 신뢰성이 높을 것으로 예상됨.
  • 다중 스레드 모드에서는 알려진 버그와 데드락이 있을 수 있으며, 컴파일러가 생성하는 바이너리는 어떤 프론트엔드를 사용하든 동일해야 함.

피드백

  • 병렬 프론트엔드에 문제가 있을 경우 "WG-compiler-parallel" 라벨이 붙은 이슈를 확인하고, 새로운 이슈를 제출할 수 있음.

향후 작업

  • 병렬 프론트엔드의 성능을 개선하고 멀티 스레드 모드의 버그를 해결하는 작업이 진행 중임.
  • 2024년에 안정적인 릴리스에서 기본적으로 다중 스레드 모드로 실행되도록 -Z threads 옵션을 안정화할 계획임.

GN⁺의 의견

이 기사에서 가장 중요한 점은 Rust 컴파일러의 프론트엔드가 이제 병렬 실행을 지원하여 컴파일 시간을 크게 단축할 수 있다는 것이다. 이는 Rust 개발자들에게 컴파일 속도 향상이라는 큰 이점을 제공하며, 효율적인 개발 환경을 조성하는 데 기여할 것이다. 병렬 프론트엔드의 도입은 Rust 커뮤니티에게 흥미로운 소식이며, 성능 개선을 위한 지속적인 노력의 결과로 볼 수 있다.

▲
neo 6달전  [-]
Hacker News 의견
  • Rust 컴파일 속도 개선에 대한 기대감
    • Rust의 컴파일 속도가 느린 점이 단점으로 지적되며, 특히 대규모 저장소에서 작업할 때 CI/CD 비용 증가와 개발 시간 지연의 원인이 됨. 캐시를 제거해야 할 때(도커 버그로 인해 가끔 발생) 특히 문제가 됨. 이러한 진전에 대해 긍정적인 반응.
  • Rust 컴파일 속도에 대한 개인적 경험
    • 오래전 Rust를 사용했을 때 컴파일 속도가 느렸으나 최근 다시 사용하면서 컴파일 시간을 거의 신경 쓰지 않게 됨. 그러나 프로젝트가 커지면서 컴파일 지연이 느껴질 때가 있어, 이러한 개선이 개인적으로 매우 반가운 소식임.
  • Rust 컴파일 과정에 대한 질문
    • Rust의 프론트엔드가 빌림 검사를 마친 후 백엔드가 작업을 시작해야 하는지에 대한 질문. 백엔드가 빌림 검사 오류를 발견하면 추측적인 작업을 버릴 수 있지 않을까 하는 의문 제기.
  • Rust 바이너리 크레이트의 컴파일에 대한 관찰
    • 라이브러리 크레이트와 달리 바이너리 크레이트가 기본적으로 크고 단일 구조로 되어 있어 컴파일이 병렬화되지 않고 가장 큰 크레이트가 직렬화되는 경향이 있음. 이러한 문제에 대한 개선이 반가움.
  • CPU 코어 활용에 대한 질문
    • 컴파일 시 CPU 코어 수를 자동으로 사용하게 할 수 있는지, 아니면 다른 기계에서 사용되는 설정 파일에 고정된 값을 넣어야 하는지에 대한 질문.
  • 멀티스레드 모드의 버그에 대한 경고
    • 멀티스레드 모드에서 알려진 버그와 데드락이 있으며, 컴파일이 멈추면 이러한 문제 중 하나를 겪었을 가능성이 있음. -Z threads 옵션 사용에 조심스러운 태도.
  • Rust 컴파일 속도의 현재 상태에 대한 긍정적인 평가
    • 몇 년간 Rust를 사용하지 않다가 최근 다시 사용해보니 컴파일 속도가 거의 즉각적임. ChatGPT와 같은 도구를 사용해 이전에는 해결하기 어려웠던 Rust 문제들을 쉽게 해결할 수 있게 되어 현재 상태가 매우 좋음.
  • Rust 컴파일 최적화의 방향성에 대한 의문
    • Rust 컴파일이 이미 파일 수준에서 고도로 병렬화되어 있는데, 단일 파일 컴파일 속도가 빨라지는 것이 상위 수준의 파일 병렬화에서 자원을 빼앗는 것은 아닌지 우려. 이에 대한 구체적인 데이터가 없다는 점이 문제로 지적됨.
  • Rust 컴파일 속도 개선에 대한 환영의 댓글
답변달기