3 ms·

No mention of the work being done on the CraneLift backend for Rust. [0] That seems like a great solution: have one compiler that runs quickly, for development,

No mention of the work being done on the CraneLift backend for Rust. [0] That seems like a great solution: have one compiler that runs quickly, for development, and have a different compiler for release builds, capable of state-of-the-art optimisation. My understanding is that compile times can be greatly improved simply by using a faster (and less optimising) code-generator, even without doing the (presumably much harder) work of optimising Rust's borrower-checker. Disclaimer: I don't know all that much about Rust. [0] https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift

edflsafoiewq 6y ago
My impression was cranelift doesn't improve compile time by enough to lift rustc out of the "slow" category, and borrowck isn't usually the expensive part of compilation.
- MaxBarraclough 6y ago
  If not the borrower-checker or the code-generator, what's the slow part of Rust compilation? The front-end?
  - trait 6y ago
    The slowest part is code-gen indeed, that's why cargo-check[0] is really fast. [0]https://doc.rust-lang.org/cargo/commands/cargo-check.html https://doc.rust-lang.org/cargo/commands/cargo-check.html
  - zozbot234 6y ago
    Typically the bottleneck is monomorphizing generic code. Also evaluating macros (if they're being used).
Thaxll 6y ago
Having two different compiler is tricky because that means what you dev and what goes to prod are different?
- tonyedgecombe 6y ago
  That’s the case with other compiled languages as the debug and release builds have different optimisations.
- MaxBarraclough 6y ago
  Could be an issue, but it's one with various possible solutions. Devs could switch to the LLVM-backed compiler periodically, a continuous integration system could run both compilers, etc. If both compilers are relatively bug-free it shouldn't be too much of a burden. Correct C/C++ code runs fine under both GCC and Clang, for example. If anything, things should be easier with Rust, as it gives you less opportunity to shoot yourself in the foot in strange compiler-specific ways than do C and C++. I recall having a C++ alignment issue that only arose in one compiler, for example. (Of course, my code was broken, but it worked ok with one of the compilers just 'by coincidence'.) I figure that kind of thing is less likely in Rust, but I don't know the Rust language well enough to say this with confidence.

edflsafoiewq 6y ago

My impression was cranelift doesn't improve compile time by enough to lift rustc out of the "slow" category, and borrowck isn't usually the expensive part of compilation.

MaxBarraclough 6y ago
If not the borrower-checker or the code-generator, what's the slow part of Rust compilation? The front-end?
- trait 6y ago
  The slowest part is code-gen indeed, that's why cargo-check[0] is really fast. [0]https://doc.rust-lang.org/cargo/commands/cargo-check.html https://doc.rust-lang.org/cargo/commands/cargo-check.html
- zozbot234 6y ago
  Typically the bottleneck is monomorphizing generic code. Also evaluating macros (if they're being used).

Thaxll 6y ago

Having two different compiler is tricky because that means what you dev and what goes to prod are different?

tonyedgecombe 6y ago
That’s the case with other compiled languages as the debug and release builds have different optimisations.
MaxBarraclough 6y ago
Could be an issue, but it's one with various possible solutions. Devs could switch to the LLVM-backed compiler periodically, a continuous integration system could run both compilers, etc. If both compilers are relatively bug-free it shouldn't be too much of a burden. Correct C/C++ code runs fine under both GCC and Clang, for example. If anything, things should be easier with Rust, as it gives you less opportunity to shoot yourself in the foot in strange compiler-specific ways than do C and C++. I recall having a C++ alignment issue that only arose in one compiler, for example. (Of course, my code was broken, but it worked ok with one of the compilers just 'by coincidence'.) I figure that kind of thing is less likely in Rust, but I don't know the Rust language well enough to say this with confidence.