this post was submitted on 24 Mar 2024
22 points (92.3% liked)

Rust

5943 readers
2 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 9 points 7 months ago (3 children)

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.

[–] [email protected] 3 points 7 months ago (1 children)

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.

[–] [email protected] 1 points 7 months ago

Yes. And to complete the pro tips, the choice of linker can be very relevant. Using mold would come recommended nowadays.

[–] [email protected] 1 points 7 months ago (1 children)

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?

[–] [email protected] 2 points 7 months ago

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 special release-dev profile. A developer does not have to be limited in how they modify or construct their profiles.

[–] [email protected] 0 points 7 months ago (1 children)

Please, send an email to [email protected] to report this issue to them, they usually fix things quickly.

[–] [email protected] 4 points 7 months ago

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.

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-cl