-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
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
Enable parallel builds by default (at least enableParallelBuilding = true
)
#142338
Comments
Thank you very much that you are taking the time to debug and optimise this! This is very much appreciated especially when building staging. ❤️ |
might be worth checking out the comments of packages that disable it
|
I would hazard a guess that most of the parallel fails are from raw makefiles. Usually autoconf generates sound dependency graphs but hand-written make rules can be dicey. Does that line up with the results from your PoC sample? |
Yeah, examples roughly match it (if we do s/autoconf/automake/). |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfc-make-stdenv-to-build-in-parallel-by-default/15684/1 |
I started with reaverwps, I tried tomboy as well but it is broken... I think I should make a PR removing tomboy entirely as upstream development halted more than 3 years ago @trofi I'll try to help getting this list done, I have a machine with 8 cores and one with 32 |
That's perfect. Thank you! |
Vast majority of packages can be built in parallel without problems. My initial goal was to speed up initial bootstrap slightly where packages like `bison` or `coreutils` happened to build sequentially kist because it's a default. This change flips the default to parallel builds for make-based derivations. We expect some build failure fallou which in worst case should be easy to fix with: # <why it fails> enableParallelBuilding = false; Issue: NixOS#142338
I think one of the problems behind this is finding a way to correctly capture knowledge about the package. Something like a trinary here would be very useful:
This records a fact about the software being built, and is less about the policy of how to build it. I wonder if we could use/abuse the To be clear, I am then in favor of setting it to be enabled by default. |
Although it's highly desirable to have parallel builds, not all projects have build logic which supports being built in parallel; so I don't think this can be adopted by default. Recent example: intel/linux-sgx#784 (comment) These issues are also very common in the python ecosystem, where pytest-xdist will cause certain assumptions to become invalid. I've also seen clang and gcc SEGFAULT on builds with cores>32. |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfc-make-stdenv-to-build-in-parallel-by-default/15684/8 |
I keep stumbling on packages that use sequential build for seemingly no reason:
On big parallel machines you can interactively notice which ones do not enable parallel builds and take more than a few seconds to build (especially during bootstrap).
Let's enable parallel builds by default and disable parallelism of select packages that break.
Many build systems already enable parallel builds. To name a few:
About 1300 packages set
enableParallelBuilding = true;
.PoC implementation for
stdenv
+make
packages:Example run of this PoC on set of packages from my NixOS desktop reveals at least ~20 failures (of 2100 packages), ~1% of failures. For all of
nixpkgs
if we extrapolate to 40000 packages that should be about 400 failures (very rough estimate). Does not sound too bad, but needs a hydra run to get most of them before the default flip.Some examples (to be fixed / worked around).
xfce.garcon:fails occasionally regardless of build parallelism: autoconf: pull upstream fix for autoreconf race #144998The text was updated successfully, but these errors were encountered: