백엔드와 최적화는 서로 다른 크레이트(crates)에 대해 다르게 사용할 수 있음. 의존성에 대해서는 최적화된 LLVM 빌드를 사용하고, 자신의 코드에 대해서는 디버그 LLVM이나 Cranelift를 사용하는 것이 종종 의미가 있음.
최적화 속도 대 최적화 품질에 대한 훌륭한 개요를 제공하는 기사. 특히, 사전 컴파일된 코드를 사용하는 복사-패치 컴파일이 여전히 가장 빠르지만 최적화에는 여지가 적음. Cranelift는 IR에서 동등성을 나타내기 위해 e-graphs를 사용하여 복사-패치 접근법보다 더 많은 최적화를 가능하게 함. 가장 최적화된 출력은 LLVM이나 GCC와 같은 전통적인 컴파일러 툴체인에서 나오겠지만, "충분히 빠른" 출력을 가능한 빨리 얻고자 하는 사용자들에게는 새로운 컴파일러 기술이 유망한 대안을 제공함.
전체 디버그 빌드에 대한 많은 댓글이 있지만, 작은 변경 사항에 대한 증분 빌드 시간이 가장 중요한 차이라고 생각함. 이것이 개발 반복을 가속화하는 것임. rust-analyzer와 gleam 프로젝트에서 작은 변경을 한 후의 빌드 시간을 비교했을 때, Cranelift와 mold를 추가한 경우가 훨씬 빠른 개선을 보임. Go 언어로 빌드된 Terraform과 비교해도 Rust의 큰 개선 사항을 보여줌.
M1-M3 Mac 지원이 현재 없고 Windows 지원도 없는 것 같음. 가장 활발한 기여자의 최신 업데이트가 결론이 모호함. Windows 지원은 현재 생략되었고, macOS는 현재 x86_64만 지원함. M1 프로세서를 사용하는 경우 x86_64 버전의 rustc를 설치하고 Rosetta 2를 사용해 볼 수 있지만, Rosetta 2는 성능에 영향을 줄 수 있으므로 LLVM 백엔드와 비교해 봐야 함.
Bevy 프로젝트에서 기사의 지침을 시도해 보고 "정상" 빌드와 비교함. Cranelift+debug 빌드와 비교해 릴리스 빌드가 빠른 것처럼 보이지만, sccache와 로컬 NAS를 사용해 캐싱하기 때문임. 캐싱 없이 디버그 빌드만 다시 시도했을 때, 컴파일 시간이 절반 가까이 줄어듦.
Equality Graphs 링크를 통해 ESC/Java를 발견함. ESC/Java를 실제로 시도해 보거나 성공한 사람이 있는지 궁금함. Spot bugs(이전에는 Findbugs로 알려짐)와 비교해 보는 것이 흥미로움.
Cranelift를 사용한 디버그 빌드가 개발 반복 속도를 높여줄 것에 대해 매우 기대됨. 특히 WASM/Frontend Rust에서 반복 속도가 중요한데, Rust 도구의 새 시대가 때때로 1초 미만의 빌드를 제공함. 아직 ARM macOS를 지원하지 않아 M1-3 사용자는 조금 기다려야 함.
Cranelift를 사용했을 때의 런타임(컴파일 시간이 아닌) 벤치마크가 있는지 궁금함. 기사에서 "두 배 느림"이라고 언급되었지만, 그 데이터는 2020년 기준임. 그 이후로 상당히 개선되었는지 궁금함.
Cranelift가 LLVM보다 빠를 것으로 예상되는 이유와 그 개선 사항이 LLVM에도 적용될 수 없는 이유를 설명해 줄 수 있는 사람이 있는지 궁금함.
Hacker News 의견