Skip to content
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

Closed
16 of 28 tasks
trofi opened this issue Oct 20, 2021 · 10 comments
Closed
16 of 28 tasks

Enable parallel builds by default (at least enableParallelBuilding = true) #142338

trofi opened this issue Oct 20, 2021 · 10 comments
Labels
0.kind: enhancement Add something new

Comments

@trofi
Copy link
Contributor

trofi commented Oct 20, 2021

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:

  • dotent
  • ocaml
  • go
  • haskell

About 1300 packages set enableParallelBuilding = true;.

PoC implementation for stdenv + make packages:

--- a/pkgs/stdenv/generic/make-derivation.nix
+++ b/pkgs/stdenv/generic/make-derivation.nix
@@ -60,6 +60,8 @@ in
     (stdenv.hostPlatform != stdenv.buildPlatform)
     [ "build" "host" ]

+, enableParallelBuilding ? true
+
 # TODO(@Ericson2314): Make unconditional / resolve #33599
 # Check phase
 , doCheck ? config.doCheckByDefault or false
@@ -310,7 +312,8 @@ else let
           llvm-config = 'llvm-config-native'
         '';
       in [ "--cross-file=${crossFile}" ] ++ mesonFlags;
-    } // lib.optionalAttrs (attrs.enableParallelBuilding or false) {
+    } // lib.optionalAttrs enableParallelBuilding {
+      inherit enableParallelBuilding;
       enableParallelChecking = attrs.enableParallelChecking or true;
     } // lib.optionalAttrs (hardeningDisable != [] || hardeningEnable != [] || stdenv.hostPlatform.isMusl) {
       NIX_HARDENING_ENABLE = enabledHardeningOptions;

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).

@trofi trofi added the 0.kind: bug Something is broken label Oct 20, 2021
@SuperSandro2000
Copy link
Member

Thank you very much that you are taking the time to debug and optimise this! This is very much appreciated especially when building staging. ❤️

@Artturin
Copy link
Member

might be worth checking out the comments of packages that disable it

rg -SpL -C 1 'enableParallelBuilding = false;' | less -RF

@r-burns
Copy link
Contributor

r-burns commented Oct 22, 2021

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?

@trofi
Copy link
Contributor Author

trofi commented Oct 22, 2021

Yeah, examples roughly match it (if we do s/autoconf/automake/).

@nixos-discourse
Copy link

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

@dasj19
Copy link
Contributor

dasj19 commented Jan 27, 2022

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

@dasj19 dasj19 mentioned this issue Jan 27, 2022
13 tasks
@trofi
Copy link
Contributor Author

trofi commented Jan 27, 2022

That's perfect. Thank you!

trofi added a commit to trofi/nixpkgs that referenced this issue Feb 4, 2022
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
@grahamc
Copy link
Member

grahamc commented Feb 5, 2022

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:

parallelBuilds = unknown | known-bad | known-good;

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 meta type checking: https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/check-meta.nix to validate ternary status, assume it being undefined / null means "unknown", and then derive "enableParallelBuilding" from that.

To be clear, I am then in favor of setting it to be enabled by default.

cc @7c6f434c @roberth

@jonringer
Copy link
Contributor

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.

@trofi trofi closed this as completed Feb 5, 2022
@nixos-discourse
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: enhancement Add something new
Projects
None yet
Development

No branches or pull requests

9 participants