New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustc: enable codegen units and parallel building #21742
Conversation
I remember only commenting that line. Didn't see any problems after that. Before that I didn't use rust so I don't know :) Is codegen=10 really necessary? Where did you find that number? Quick google search gives me:
|
This is just for building the rust compiler itself, I can imagine that for most rust packages a value of more then 4 won't matter. |
@@ -52,6 +42,9 @@ stdenv.mkDerivation { | |||
# versions. | |||
RUSTC_BOOTSTRAP = "1"; | |||
|
|||
# Increase codegen units to introduce parallelism within the compiler. | |||
RUSTFLAGS = "-Ccodegen-units=10"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should set this in preBuild
? Spares us the re-exporting in checkPhase
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should set this only if enableParallelBuilding
is set to true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That won't help, you'll still have to disable it before the checkPhase
anyway. And this is more related to --cores
then parallel building, it's still a single rustc
process if you use this with parallel building enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! I didn't know that. Sounds fine to me :)
outputs = [ "out" "doc" ]; | ||
setOutputFlags = false; | ||
|
||
# Disable codegen units for the tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line should be just above the export
as preCheck
does other things.
Did someone already run this with |
I did not, the rust build is entirely deterministic at the moment? |
As far as I know: Yes. Never heard of anyone running into issues with it. I tried it a version (or so) ago with |
I'll run the I also got a few other small |
I just checked my build results, looks like does indeed cause issues with reproducibility. I'm building master now to make sure that this was reproducible before. |
Aww that's a bummer :( I'm still on +1 for merging this iff it had the same issues before. It's also worth checking if the codegen stuff without In any case we should add a comment to the derivation to mark it as non-reproducible. |
Indeed, I was thinking the same thing. Running |
LGTM, let's merge? |
👍 |
@LnL7 this might have broken the build: errors like:
|
The build is also broken on my machine and reverting fixes it. |
I'll change it back to |
@LnL7 Thank you! Could this be a problem with enabling more codegen units than there are available cores? I don't know how many cores the Hydra builders have available, but I'm sure it varies. That might explain why it works for you. I will check some different settings when I have time, but for now I'm only just learning Rust! 😃 |
I'm fairly certain this issue is not related to the codegen units. My machine only has ssd and does have quite a bit of memory, perhaps that's why I'm not running into it |
@wizeman looks like you've been looking into this a fair bit. Have any more information? |
@copumpkin: No, sorry. I simply filed an upstream Rust bug (rust-lang/rust#30181) when I ran into a build failure after setting The upstream issue seems to have been marked closed with no indication that it was fixed. They asked if I could reproduce it with a current master commit but I currently don't have available time to do it. |
FYI, I built current |
Motivation for this change
This makes
rustc
build in about ~30m compared to ~1h15m on my build machine.I also noticed that patching the shebangs for the dev output is also very slow.
I'm pretty sure we don't have to do that, but I'm not sure how to disable it for a single output.
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)@retrry Did you run into issues with parallel builds? I have built a bunch of times now before I figured out what was causing the tests to fail and I have not seen any issues with it.