-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Optimize validator binaries with LTO #4311
Comments
cc @s3krit |
And cc @chevdor Please realize this already for the 0.9.13 release. I would also propose that we push a commit to each release branch that adds |
Do you know how much does We can also add |
Just fyi, |
|
FYI, other optimizations that we tried:
|
The compilation flags provided in the OP ( |
Latest rust release is bringing exactly what we want here! Custom profiles: https://blog.rust-lang.org/2021/12/02/Rust-1.57.0.html#cargo-support-for-custom-profiles |
So the binaries are using the flags, but the benchmarks are run without, right? @s3krit |
Why would you not add it to your benchmarking workflows as well btw ? |
This is coming up soon paritytech/substrate#10608 |
I do not see anything regarding |
@ggwpez I do confirm that we do use it for the builds but this is rather ad'hoc right now and we should simply build using the profile in the Cargo.toml. I will make a PR to fix that. In the meantime, I do confirm that we build using:
|
* Add codeden-units=1 ref #4311 * opt-level to 3 * Fix opt-level * Refactor apt-level into the release profile
* Add codeden-units=1 ref #4311 * opt-level to 3 * Fix opt-level * Refactor apt-level into the release profile
* Update deps * Fix release profile (#4778) * Add codeden-units=1 ref #4311 * opt-level to 3 * Fix opt-level * Refactor apt-level into the release profile fix #4780 * wrong if-case - backport of #4798 into v0.9.16 (#4800) * fixup * fmt * fix tests * Rk fix sorting 0.9.16 (#4806) * Fix incomplete sorting. * fmt. * Better test. * Update runtime/parachains/src/disputes.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * cargo fmt Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Refactor check validation outputs - Backport of #4727 into v0.9.16 (#4801) * Move PersistedValidationData check into * Address feedback * Remove incorrect comment * Update runtime/parachains/src/inclusion/mod.rs * fmt * Add logging Co-authored-by: Robert Habermeier <rphmeier@gmail.com> Co-authored-by: Andronik <write@reusable.software> Co-authored-by: Bernhard Schuster <bernhard@ahoi.io> Co-authored-by: Robert Klotzner <eskimor@users.noreply.github.com> Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> Co-authored-by: Lldenaurois <ljdenaurois@gmail.com> Co-authored-by: Robert Habermeier <rphmeier@gmail.com> Co-authored-by: Andronik <write@reusable.software>
* Add codeden-units=1 ref paritytech#4311 * opt-level to 3 * Fix opt-level * Refactor apt-level into the release profile
I'm curious what the status is here? If in CI we already build production binaries with LTO, can this be closed? (Not sure we should always have |
Currently, the polkadot binary is generated with the default release profile. This allow a good binary with a decent compilation time.
However using compilations options
CARGO_PROFILE_RELEASE_LTO=true RUSTFLAGS="-C codegen-units=1" cargo build --release
, it provides a much more efficient binary, 200-400% cpu perf (at the cost of twice longer to compile).I suggest to not include it in the Cargo.toml to avoid people developing on it to get a longer compilation time. In Moonbeam, we include it only in the CI for the release binary and we added those flags in the documentation for operators building their own binary.
I believe it is important to start optimizing the validators as it is becoming a bottleneck to process the parachain blocks in time.
The text was updated successfully, but these errors were encountered: