Allow build to be interrupted and continue from where it left off like rest of nix pkgs #512

New issue

Closed

opened 2024-09-10 09:54:47 +00:00 by mkb2091 · 2 comments

mkb2091 commented

2024-09-10 09:54:47 +00:00

It can be annoying when rebuilding system when it needs to build the latest version of lix, if it is interrupted it started from 0/485 instead of resuming from where it left

Describe the solution you'd like

If it was built as multiple derivations instead of one large package then it would only need to compile the components that haven't yet been compiled instead of recompiling whole program which can take a while on slow devices.

Describe alternatives you've considered

When the latest version is in the build cache it will be less of an issue to end users.

## Is your feature request related to a problem? Please describe. It can be annoying when rebuilding system when it needs to build the latest version of lix, if it is interrupted it started from 0/485 instead of resuming from where it left ## Describe the solution you'd like If it was built as multiple derivations instead of one large package then it would only need to compile the components that haven't yet been compiled instead of recompiling whole program which can take a while on slow devices. ## Describe alternatives you've considered When the latest version is in the build cache it will be less of an issue to end users.

jade commented

2024-09-10 15:04:23 +00:00

Owner

This is unlikely to happen for a few reasons, chief among them that headers (and worse, git commits in version) exist so you get a high rate of spurious downstream rebuilds and that this would actually make both parallelism and cpu scheduling worse.

Parallelism is worse because you have to wait for each derivation to finish before doing the next so you have more serialized portions for Mr. Amdahl's observations to ruin your day. There's a lot of 90th percentile compilation units that take some 20+ cpu seconds to build and they're acceptable in a fully parallel build where there's other work to do but will hold up a split derivation. CPU scheduling is worse because, to whatever extent lix modules split into fewer than hundreds of derivations can be built in parallel (most likely approximately zero; it's fully serialized because the dep graph of libstore, libutil, etc is a crime), sending nproc compilers into the cpu scheduler several times is going to cause scheduling contention and delays.

CppNix has actually implemented this derivation split in their meson build and personally I'm quite skeptical of it. I would suggest perhaps timing it compared to Lix (I suspect that our pretty-serious build time work is likely to make a clear winner but I don't know).

The one conceivable way this could actually save time is for stuff that doesn't change between builds, and currently the only really plausible example of that is lix-doc, but that takes about 10 cpu seconds to build out of a thousand (the entire lix builds in a minute or two on my machine; parallelism is magic).

This is unlikely to happen for a few reasons, chief among them that headers (and worse, git commits in `version`) exist so you get a high rate of spurious downstream rebuilds and that this would actually make both parallelism and cpu scheduling worse. Parallelism is worse because you have to wait for each derivation to finish before doing the next so you have more serialized portions for Mr. Amdahl's observations to ruin your day. There's a lot of 90th percentile compilation units that take some 20+ cpu seconds to build and they're acceptable in a fully parallel build where there's other work to do but will hold up a split derivation. CPU scheduling is worse because, to whatever extent lix modules split into fewer than hundreds of derivations can be built in parallel (most likely approximately zero; it's fully serialized because the dep graph of libstore, libutil, etc is a crime), sending `nproc` compilers into the cpu scheduler several times is going to cause scheduling contention and delays. CppNix has actually implemented this derivation split in their meson build and personally I'm quite skeptical of it. I would suggest perhaps timing it compared to Lix (I suspect that our pretty-serious build time work is likely to make a clear winner but I don't know). The one conceivable way this could actually save time is for stuff that doesn't *change* between builds, and currently the only really plausible example of that is lix-doc, but that takes about 10 cpu seconds to build out of a thousand (the entire lix builds in a minute or two on my machine; parallelism is magic).

jade closed this issue

2024-09-10 15:04:23 +00:00

jade commented

2024-09-10 15:08:47 +00:00

Owner

This isn't promoted to the official docs yet since 2.91 took a while to get into 24.05. Or use the official docs that set nix.package. There will be a few things with the wrong nix due to putting the path into scripts including possibly nixos-rebuild, but you won't wait for any rebuilds.

To solve your actual problem, see the README of lix-module (assuming you're on NixOS unstable; for 24.05, wait 3-5 days because the PR for 2.91 was merged just now), under the section to use the module with lix from nixpkgs. This isn't promoted to the official docs yet since 2.91 took a while to get into 24.05. Or use the official docs that set nix.package. There will be a few things with the wrong nix due to putting the path into scripts including possibly nixos-rebuild, but you won't wait for any rebuilds.

jade added the

Status

wontfix

label 2024-09-10 15:18:23 +00:00

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#512

No description provided.