Users can now use Cranelift as the code-generation backend for debug builds of projects written in Rust
Didn’t read the rest. But this is clearly inaccurate, as most Rustaceans probably already know.
Cranelift can be used in release builds. The performance is not competitive with LLVM. But some projects are completely useless (too slow) when built with the debug profile. So, some of us use a special release profile where Cranelift backend is used, and debug symbols are not stripped. This way, one can enjoy a quicker edit/compile/debug cycle with usable, if not the best, performance in built binaries.
Another option is to compile dependencies with LLVM and optimizations, which will likely be done only once in the first clean build, and then compile your main binary with Cranelift, thus getting the juicy fast compile times without having to worry about the slow dependencies.
I read the rest of the article, and it appears to have been partially written before support for codegen backends landing in cargo.
The latest progress report from bjorn3 includes additional details on how to configure Cargo to use the new backend by default, without an elaborate command-line dance.
So that “special release build” is the build you do debugging with. Shouldn’t you just modify the otherwise useless debug profile and turn on all the optimizations necessary to make it usable?
And the debug (dev) profile has its uses. It’s just not necessarily the best for typical day-to-day development in many projects.
I actually use two steps of profile inheritance, with -cl (for Cranelift) inheriting from a special release-dev profile. A developer does not have to be limited in how they modify or construct their profiles.
Didn’t read the rest. But this is clearly inaccurate, as most Rustaceans probably already know.
Cranelift can be used in release builds. The performance is not competitive with LLVM. But some projects are completely useless (too slow) when built with the debug profile. So, some of us use a special release profile where Cranelift backend is used, and debug symbols are not stripped. This way, one can enjoy a quicker edit/compile/debug cycle with usable, if not the best, performance in built binaries.
Another option is to compile dependencies with LLVM and optimizations, which will likely be done only once in the first clean build, and then compile your main binary with Cranelift, thus getting the juicy fast compile times without having to worry about the slow dependencies.
Yes. And to complete the pro tips, the choice of linker can be very relevant. Using
moldwould come recommended nowadays.Please, send an email to lwn@lwn.net to report this issue to them, they usually fix things quickly.
I read the rest of the article, and it appears to have been partially written before support for codegen backends landing in cargo.
That “latest progress report” has the relevant info ;)
So, basically, you would add this to the top of
Cargo.toml:cargo-features = ["codegen-backend"]Then add a custom profile, for example:
[profile.release-dev-cl] inherits = "release" lto = "off" debug = "full" codegen-backend = "cranelift"Then build with:
cargo build --profile release-dev-clSo that “special release build” is the build you do debugging with. Shouldn’t you just modify the otherwise useless debug profile and turn on all the optimizations necessary to make it usable?
Well, obviously that will depend on what defaults (and how many?!) a developer is going to change".
https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles
And the debug (
dev) profile has its uses. It’s just not necessarily the best for typical day-to-day development in many projects.I actually use two steps of profile inheritance, with
-cl(for Cranelift) inheriting from a specialrelease-devprofile. A developer does not have to be limited in how they modify or construct their profiles.