| Message ID | 20240726133559.1124668-1-sundeep.kokkonda@windriver.com |
|---|---|
| State | Accepted, archived |
| Commit | 0c00875de10b171f4ff2990af351a8124ec7e972 |
| Headers | show |
| Series | rust: rustdoc reproducibility issue fix | expand |
On Fri, 26 Jul 2024 at 15:36, Sundeep KOKKONDA via lists.openembedded.org <sundeep.kokkonda=windriver.com@lists.openembedded.org> wrote: > +rust: rustdoc reproducibility issue fix > + > +rust: rustdoc reproducibility issue fix > + > +The 'codegen-units' option split the crate into multiple compilation units for parallel compilation. Currently, this split is causing the rustdoc to generate differnt binary between the builds. > +To fix this the codegen-units & the lto options are disabled. I just ran some benchmarks to see how much disabling parallel codegen-units affects build times (the parallelism is only at the crate level after this change), and unfortunately the increase has been significant. As of current master, rust 1.81.0: rust-native 527 seconds -> 853 seconds rust 1123 seconds -> 1688 seconds I presume the codegen-units parallel issue can be fixed properly by adding a sort somewhere for determinism, but finding that spot is probably very challenging. We do need to get to it though. Can you please point to the request/effort to set up reproducibility tests upstream? Alex
On 28-Jan-25 17:22, Alexander Kanavin wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Fri, 26 Jul 2024 at 15:36, Sundeep KOKKONDA via > lists.openembedded.org > <sundeep.kokkonda=windriver.com@lists.openembedded.org> wrote: >> +rust: rustdoc reproducibility issue fix >> + >> +rust: rustdoc reproducibility issue fix >> + >> +The 'codegen-units' option split the crate into multiple compilation units for parallel compilation. Currently, this split is causing the rustdoc to generate differnt binary between the builds. >> +To fix this the codegen-units & the lto options are disabled. > I just ran some benchmarks to see how much disabling parallel > codegen-units affects build times (the parallelism is only at the > crate level after this change), and unfortunately the increase has > been significant. > > As of current master, rust 1.81.0: > > rust-native 527 seconds -> 853 seconds > rust 1123 seconds -> 1688 seconds > > I presume the codegen-units parallel issue can be fixed properly by > adding a sort somewhere for determinism, but finding that spot is > probably very challenging. We do need to get to it though. > > Can you please point to the request/effort to set up reproducibility > tests upstream? Sure Alex, I will look into it the ways to optimize it. As I remember, when the 'codegen-units' count is increased it is causing /rustdoc /binaries are not reproducible. I've to re-test it with some higher values of 'codegen-units' on latest rust sources. I'll test that. Thanks, Sundeep K. > > Alex
> I just ran some benchmarks to see how much disabling parallel > codegen-units affects build times (the parallelism is only at the > crate level after this change), and unfortunately the increase has > been significant. > > As of current master, rust 1.81.0: > > rust-native 527 seconds -> 853 seconds > rust 1123 seconds -> 1688 seconds > > I presume the codegen-units parallel issue can be fixed properly by > adding a sort somewhere for determinism, but finding that spot is > probably very challenging. We do need to get to it though. > > Can you please point to the request/effort to set up reproducibility > tests upstream? > > Sure Alex, I will look into it the ways to optimize it. As I remember, when the 'codegen-units' count is increased it is causing rustdoc binaries are not reproducible. > > I've to re-test it with some higher values of 'codegen-units' on latest rust sources. I'll test that. You can simply drop the patch and then rust will pick a default value of 16 for it. On 1.81.0 that still makes rustdoc unreproducible, I just checked that. Alex
On 29-Jan-25 11:02, Alexander Kanavin wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > >> I just ran some benchmarks to see how much disabling parallel >> codegen-units affects build times (the parallelism is only at the >> crate level after this change), and unfortunately the increase has >> been significant. >> >> As of current master, rust 1.81.0: >> >> rust-native 527 seconds -> 853 seconds >> rust 1123 seconds -> 1688 seconds >> >> I presume the codegen-units parallel issue can be fixed properly by >> adding a sort somewhere for determinism, but finding that spot is >> probably very challenging. We do need to get to it though. >> >> Can you please point to the request/effort to set up reproducibility >> tests upstream? >> >> Sure Alex, I will look into it the ways to optimize it. As I remember, when the 'codegen-units' count is increased it is causing rustdoc binaries are not reproducible. >> >> I've to re-test it with some higher values of 'codegen-units' on latest rust sources. I'll test that. > You can simply drop the patch and then rust will pick a default value > of 16 for it. On 1.81.0 that still makes rustdoc unreproducible, I > just checked that. Thanks for confirmation Alex. We already have an open issue for the reproducibility issue with rust community and there the /rustdoc /issue with 'codegen_units' also mentioned. https://github.com/rust-lang/rust/issues/134589#issue-2753629767 We will work with upstream to find the proper fix for this issue. Thanks, Sundeep K. > > Alex
On Thu, 30 Jan 2025 at 04:24, Sundeep KOKKONDA <Sundeep.Kokkonda@windriver.com> wrote: > Sure Alex, I will look into it the ways to optimize it. As I remember, when the 'codegen-units' count is increased it is causing rustdoc binaries are not reproducible. > > I've to re-test it with some higher values of 'codegen-units' on latest rust sources. I'll test that. > > You can simply drop the patch and then rust will pick a default value > of 16 for it. On 1.81.0 that still makes rustdoc unreproducible, I > just checked that. > > Thanks for confirmation Alex. > > We already have an open issue for the reproducibility issue with rust community and there the rustdoc issue with 'codegen_units' also mentioned. > > https://github.com/rust-lang/rust/issues/134589#issue-2753629767 > > > We will work with upstream to find the proper fix for this issue. I spent some time looking into rustdoc again. While I couldn't quite get to the bottom of the issue (it's a deeply esoteric llvm subject), I was at least able to produce a better reproducibility work-around: https://patchwork.yoctoproject.org/project/oe-core/patch/20250204104205.3423548-1-alex.kanavin@gmail.com/ Alex
diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py b/meta/lib/oeqa/selftest/cases/reproducible.py index 5460f158e5..3d3f30eebc 100644 --- a/meta/lib/oeqa/selftest/cases/reproducible.py +++ b/meta/lib/oeqa/selftest/cases/reproducible.py @@ -16,8 +16,6 @@ import os import datetime exclude_packages = [ - 'rust-rustdoc', - 'rust-dbg' ] def is_excluded(package): diff --git a/meta/recipes-devtools/rust/files/rustdoc-repro-issue-fix-cargo-config-for-codegenunits.patch b/meta/recipes-devtools/rust/files/rustdoc-repro-issue-fix-cargo-config-for-codegenunits.patch new file mode 100644 index 0000000000..0aab8772eb --- /dev/null +++ b/meta/recipes-devtools/rust/files/rustdoc-repro-issue-fix-cargo-config-for-codegenunits.patch @@ -0,0 +1,26 @@ +rust: rustdoc reproducibility issue fix + +rust: rustdoc reproducibility issue fix + +The 'codegen-units' option split the crate into multiple compilation units for parallel compilation. Currently, this split is causing the rustdoc to generate differnt binary between the builds. +To fix this the codegen-units & the lto options are disabled. + +More info about options: +https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units +https://doc.rust-lang.org/rustc/codegen-options/index.html#lto + +Upstream-Status: Inappropriate [oe specific] + +Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@windriver.com> +--- +--- a/.cargo/config.toml ++++ b/.cargo/config.toml +@@ -3,3 +3,7 @@ + + [source.vendored-sources] + directory = "vendor" ++ ++[profile.release] ++codegen-units = 1 ++ + diff --git a/meta/recipes-devtools/rust/rust-source.inc b/meta/recipes-devtools/rust/rust-source.inc index 20ef5e82bc..facf6eb346 100644 --- a/meta/recipes-devtools/rust/rust-source.inc +++ b/meta/recipes-devtools/rust/rust-source.inc @@ -13,6 +13,7 @@ SRC_URI += "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n file://0001-Handle-vendored-sources-when-remapping-paths.patch;patchdir=${RUSTSRC} \ file://repro-issue-fix-with-v175.patch;patchdir=${RUSTSRC} \ file://0001-cargo-do-not-write-host-information-into-compilation.patch;patchdir=${RUSTSRC} \ + file://rustdoc-repro-issue-fix-cargo-config-for-codegenunits.patch;patchdir=${RUSTSRC} \ " SRC_URI[rust.sha256sum] = "4526f786d673e4859ff2afa0bab2ba13c918b796519a25c1acce06dba9542340" diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb b/meta/recipes-devtools/rust/rust_1.75.0.bb index bb10c852b4..eae1f28bb8 100644 --- a/meta/recipes-devtools/rust/rust_1.75.0.bb +++ b/meta/recipes-devtools/rust/rust_1.75.0.bb @@ -136,6 +136,7 @@ python do_configure() { config.add_section("rust") config.set("rust", "rpath", e(True)) config.set("rust", "remap-debuginfo", e(True)) + config.set("rust", "lto", "\"off\"") config.set("rust", "channel", e(d.expand("${RUST_CHANNEL}"))) # Whether or not to optimize the compiler and standard library