pkgs/top-level/release-outpaths-parallel.nix 5x faster eval checks#269403
Conversation
There was a problem hiding this comment.
Did you try nix-eval-jobs, it does parallel but doesn't help with memory usage AFAIK
There was a problem hiding this comment.
It helps with memory usage as well because it restarts workers if they take too much memory. The chunking at the moment might be less ideal because it doesn't chunk the list into X parts and gives this to threads but instead starts to iterate the list from the beginning and give each thread an attribute in lexical key order. I think it would be faster if attributes closer to each other would be evaluated by the same thread to avoid evaluating the same thing twice (i.e. x86_64-linux packages evaluated on thread1 and aarch64-linux packages on thread2).
There was a problem hiding this comment.
However from my tests I would say that having more threads than CPUs will actually slow you down because you end up evaluating the same thing more. I usually have less threads than cores for large package sets like nixpkgs to avoid duplicating work and rather trait it for memory.
|
(Sorry, GitHub mobile fat finger...... Love how there's no confirmation...) |
|
I would like to note that using this in ofborg would mean giving up the performance report, at least as it is today. |
|
Conceptually this PR works similarly to how nix-eval-jobs works, just implemented as a pile of shell/nix instead of using the evaluator directly. |
This commit vendors `outpaths.nix` from ofborg commit 74f38efa7ef6f0e8e71ec3bfc675ae4fb57d7491
Partly taken from NixOS#352808 and NixOS#269403
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Motivated by ofborg struggling [1] and its evaluations taking too long, inspired by Jörg's initial PR [2] and Adam's previous attempt to parallelise Nixpkgs evaluation [3], this PR contains initial work to relief ofborg from its evaluation duty by using GitHub Actions to evaluate Nixpkgs. For now this doesn't take care of all of what ofborg does, such as requesting appropriate reviewers or labeling mass rebuilds, but this can be follow-up work. [1]: https://discourse.nixos.org/t/infrastructure-announcement-the-future-of-ofborg-your-help-needed/56025?u=infinisil [2]: NixOS#352808 [3]: NixOS#269403 Co-Authored-By: Jörg Thalheim <[email protected]> Co-Authored-By: Adam Joseph <[email protected]>
* [WIP] Parallel GH actions workflow for Nixpkgs eval Partly taken from NixOS#352808 and NixOS#269403 * ci/parallel.nix: nixfmt * ci/eval: drop swap Turns out we don't actually need it * ci/eval: reformat with shfmt the file was using mixed indentation (2 vs 4 spaces) * ci/eval: depend on coreutils nproc is only part of coreutils and not present on macOS * ci/eval: allow to override cores this is useful to control how much RAM is used during evaluation * ci/eval: use xargs instead of parallel saves us from having to install perl for this script. * ci/eval: add quick test flag * ci/eval: seperate different outputs in json * WIP * Update README.md --------- Co-authored-by: Silvan Mosberger <[email protected]> Co-authored-by: Jörg Thalheim <[email protected]> Co-authored-by: Silvan Mosberger <[email protected]>
Motivated by ofborg struggling [1] and its evaluations taking too long, inspired by Jörg's initial PR [2] and Adam's previous attempt to parallelise Nixpkgs evaluation [3], this PR contains initial work to relief ofborg from its evaluation duty by using GitHub Actions to evaluate Nixpkgs. For now this doesn't take care of all of what ofborg does, such as requesting appropriate reviewers or labeling mass rebuilds, but this can be follow-up work. [1]: https://discourse.nixos.org/t/infrastructure-announcement-the-future-of-ofborg-your-help-needed/56025?u=infinisil [2]: NixOS#352808 [3]: NixOS#269403 Co-Authored-By: Jörg Thalheim <[email protected]> Co-Authored-By: Adam Joseph <[email protected]>
Motivated by ofborg struggling [1] and its evaluations taking too long, inspired by Jörg's initial PR [2] and Adam's previous attempt to parallelise Nixpkgs evaluation [3], this PR contains initial work to relief ofborg from its evaluation duty by using GitHub Actions to evaluate Nixpkgs. For now this doesn't take care of all of what ofborg does, such as requesting appropriate reviewers or labeling mass rebuilds, but this can be follow-up work. [1]: https://discourse.nixos.org/t/infrastructure-announcement-the-future-of-ofborg-your-help-needed/56025?u=infinisil [2]: NixOS#352808 [3]: NixOS#269403 Co-Authored-By: Jörg Thalheim <[email protected]> Co-Authored-By: Adam Joseph <[email protected]>
Motivated by ofborg struggling [1] and its evaluations taking too long, inspired by Jörg's initial PR [2] and Adam's previous attempt to parallelise Nixpkgs evaluation [3], this PR contains initial work to relief ofborg from its evaluation duty by using GitHub Actions to evaluate Nixpkgs. For now this doesn't take care of all of what ofborg does, such as requesting appropriate reviewers or labeling mass rebuilds, but this can be follow-up work. [1]: https://discourse.nixos.org/t/infrastructure-announcement-the-future-of-ofborg-your-help-needed/56025?u=infinisil [2]: #352808 [3]: #269403 Co-Authored-By: Jörg Thalheim <[email protected]> Co-Authored-By: Adam Joseph <[email protected]> (cherry picked from commit fbbe972)
Motivated by ofborg struggling [1] and its evaluations taking too long, inspired by Jörg's initial PR [2] and Adam's previous attempt to parallelise Nixpkgs evaluation [3], this PR contains initial work to relief ofborg from its evaluation duty by using GitHub Actions to evaluate Nixpkgs. For now this doesn't take care of all of what ofborg does, such as requesting appropriate reviewers or labeling mass rebuilds, but this can be follow-up work. [1]: https://discourse.nixos.org/t/infrastructure-announcement-the-future-of-ofborg-your-help-needed/56025?u=infinisil [2]: NixOS#352808 [3]: NixOS#269403 Co-Authored-By: Jörg Thalheim <[email protected]> Co-Authored-By: Adam Joseph <[email protected]>
Motivated by ofborg struggling [1] and its evaluations taking too long, inspired by Jörg's initial PR [2] and Adam's previous attempt to parallelise Nixpkgs evaluation [3], this PR contains initial work to relief ofborg from its evaluation duty by using GitHub Actions to evaluate Nixpkgs. For now this doesn't take care of all of what ofborg does, such as requesting appropriate reviewers or labeling mass rebuilds, but this can be follow-up work. [1]: https://discourse.nixos.org/t/infrastructure-announcement-the-future-of-ofborg-your-help-needed/56025?u=infinisil [2]: NixOS/nixpkgs#352808 [3]: NixOS/nixpkgs#269403 Co-Authored-By: Jörg Thalheim <[email protected]> Co-Authored-By: Adam Joseph <[email protected]>
This PR is implemented entirely in pure Nix code and a single call to
xargs.Results
On a 32-core machine, the following command takes 4m58s:
and produces exactly the same output as this command (the one ofborg uses), which takes 24m10s:
... in 1/5th of the wall-clock time. So the eval-check latency is reduced by 5x. With
checkMeta=truethe ratio is almost identical: 37m54s with the current method, 7m38s withrelease-outpaths-parallel.There is room to improve even further:
release-attrpaths-superset.nixprocess. However that process produces output incrementally, meaning that the parallel part of the eval-checks can be started as soon as the first line ofrelease-attrpaths-superset.nixoutput is produced -- this should give another 25% improvement.4*NUM_CORESchunks are scheduled blindly, by simply taking alphabetical chunks of job attrpaths. This results in a huge amount of duplicated work. Simple dependency-based scheduling (possibly using the previous commit's attrpath dependency graph as an approximation of the current one) should give another large boost, possibly even 50%.Includes