!FBuJyWXTGcGtHTPphC:nixos.org

Nix Rust

704 Members
Rust164 Servers

Load older messages


SenderMessageTime
27 Mar 2026
@winter:catgirl.cloudWinteri feel like this is a dupe of another PR03:02:14
@winter:catgirl.cloudWinterjust based off memory03:02:19
@winter:catgirl.cloudWinteri’ll need to prof further tho03:02:24
@winter:catgirl.cloudWinterprod03:02:26
@niklaskorz:matrix.orgniklaskorz

@tomasajt:matrix.org already reviewed it as the author of fetchCargoVendor and stated:

I'll look into whether your approach could be improved.

In the meantime you could patch out one of the revisions in the lockfile over to the other revision. It's not guaranteed to be correct, but it might be fine as a hotfix.
12:22:29
@niklaskorz:matrix.orgniklaskorz

Or more importantly, the concerns directly above that:

I really don't see a pretty way of solving this.
Your fix seems to do its job in this case.
However, if we had both a duplicate package and a duplicate selector, even your fix wouldn't work, because we'd be back to the situation that #387337 aimed to solve.

12:24:10
29 Mar 2026
@arcayr:mischief.expertarcayr joined the room.11:15:52
@whispers:catgirl.cloudwhispers [& it/fae] so, we've been playing with rustc bootstrapping out of tree at https://codeberg.org/whispers/nebula/src/branch/meow/nix/pkgs/rust-bootstrap. the code itself is a little iffy, but we've got some initial performance metrics.
  1. reference for build perf on my laptop: nom-build -A rustc-unwrapped --check on master: 1h52m17s

  2. mrustc: 5m2s

  3. minicargo: unused. i can't find a way to get it to apply the right flags while building, so it just gets built as part of the next step.

  4. rust-1900: 1h54m18s

- this is fully using mrustc's build system. i haven't tried to optimize it at all, but i suspect you could get at least a little better perf out of it with some work.
  1. rust-1911: 17m33s

  2. rust-1920: 18m53s

  3. rust-1931: 18m1s

  4. rustc-1940: 1h48m52s

- this is just rustc-unwrapped with .override { ... }, so this is the part we build right now in nixpkgs.

(take these as order of magnitude estimates, the numbers are extremely noisy. build were run on several different days with other things running on my laptop.)

so yeah. the start and end of the chain are expensive, and both are fairly constant cost. the intermediate versions have a relatively small linear coefficient, and we've done what we're aware of to make these builds do as little work as possible (there are probably still ways to shave off a little bit of time though), but it's probably not small enough to be tenable as the distance between stable and what mrustc supports grows.
18:32:23
@whispers:catgirl.cloudwhispers [& it/fae] so, we've been playing with rustc bootstrapping out of tree at https://codeberg.org/whispers/nebula/src/branch/meow/nix/pkgs/rust-bootstrap. the code itself is pretty bad, but we've got some initial performance metrics.
  1. reference for build perf on my laptop: nom-build -A rustc-unwrapped --check on master: 1h52m17s

  2. mrustc: 5m2s

  3. minicargo: unused. i can't find a way to get it to apply the right flags while building, so it just gets built as part of the next step.

  4. rust-1900: 1h54m18s

- this is fully using mrustc's build system. i haven't tried to optimize it at all, but i suspect you could get at least a little better perf out of it with some work.
  1. rust-1911: 17m33s

  2. rust-1920: 18m53s

  3. rust-1931: 18m1s

  4. rustc-1940: 1h48m52s

- this is just rustc-unwrapped with .override { ... }, so this is the part we build right now in nixpkgs.

(take these as order of magnitude estimates, the numbers are extremely noisy. build were run on several different days with other things running on my laptop.)

so yeah. the start and end of the chain are expensive, and both are fairly constant cost. the intermediate versions have a relatively small linear coefficient, and we've done what we're aware of to make these builds do as little work as possible (there are probably still ways to shave off a little bit of time though), but it's probably not small enough to be tenable as the distance between stable and what mrustc supports grows.
18:32:34
@whispers:catgirl.cloudwhispers [& it/fae] so, we've been playing with rustc bootstrapping out of tree at https://codeberg.org/whispers/nebula/src/branch/meow/nix/pkgs/rust-bootstrap. the code itself is pretty bad, but we've got some initial performance metrics.

  1. reference for build perf on my laptop: nom-build -A rustc-unwrapped --check on master: 1h52m17s

  2. mrustc: 5m2s

  3. minicargo: unused. i can't find a way to get it to apply the right flags while building, so it just gets built as part of the next step.

  4. rust-1900: 1h54m18s

- this is fully using mrustc's build system. i haven't tried to optimize it at all, but i suspect you could get at least a little better perf out of it with some work.
  1. rust-1911: 17m33s

  2. rust-1920: 18m53s

  3. rust-1931: 18m1s

  4. rustc-1940: 1h48m52s

- this is just rustc-unwrapped with .override { ... }, so this is the part we build right now in nixpkgs.

(take these as order of magnitude estimates, the numbers are extremely noisy. build were run on several different days with other things running on my laptop.)

so yeah. the start and end of the chain are expensive, and both are fairly constant cost. the intermediate versions have a relatively small linear coefficient, and we've done what we're aware of to make these builds do as little work as possible (there are probably still ways to shave off a little bit of time though), but it's probably not small enough to be tenable as the distance between stable and what mrustc supports grows.
18:32:45
@whispers:catgirl.cloudwhispers [& it/fae] so, we've been playing with rustc bootstrapping out of tree at https://codeberg.org/whispers/nebula/src/branch/meow/nix/pkgs/rust-bootstrap. the code itself is pretty bad, but we've got some initial performance metrics.

  • reference for build perf on my laptop: nom-build -A rustc-unwrapped --check on master: 1h52m17s

  • mrustc: 5m2s

  • minicargo: unused. i can't find a way to get it to apply the right flags while building, so it just gets built as part of the next step.

  • rust-1900: 1h54m18s

* this is fully using mrustc's build system. i haven't tried to optimize it at all, but i suspect you could get at least a little better perf out of it with some work.
  • rust-1911: 17m33s

  • rust-1920: 18m53s

  • rust-1931: 18m1s

  • rustc-1940: 1h48m52s

* this is just rustc-unwrapped with .override { ... }, so this is the part we build right now in nixpkgs.

(take these as order of magnitude estimates, the numbers are extremely noisy. build were run on several different days with other things running on my laptop.)

so yeah. the start and end of the chain are expensive, and both are fairly constant cost. the intermediate versions have a relatively small linear coefficient, and we've done what we're aware of to make these builds do as little work as possible (there are probably still ways to shave off a little bit of time though), but it's probably not small enough to be tenable as the distance between stable and what mrustc supports grows.
18:33:05
@whispers:catgirl.cloudwhispers [& it/fae] so, we've been playing with rustc bootstrapping out of tree at https://codeberg.org/whispers/nebula/src/branch/meow/nix/pkgs/rust-bootstrap. the code itself is pretty bad, but we've got some initial performance metrics.

  • reference for build perf on my laptop: nom-build -A rustc-unwrapped --check on master: 1h52m17s

  • mrustc: 5m2s

  • minicargo: unused. i can't find a way to get it to apply the right flags while building, so it just gets built as part of the next step.

  • rust-1900: 1h54m18s

* this is fully using mrustc's build system. i haven't tried to optimize it at all, but i suspect you could get at least a little better perf out of it with some work.
  • rust-1911: 17m33s

  • rust-1920: 18m53s

  • rust-1931: 18m1s

  • rustc-1940: 1h48m52s

* this is just rustc-unwrapped with .override { ... }, so this is the part we build right now in nixpkgs.

(take these as order of magnitude estimates, the numbers are extremely noisy. build were run on several different days with other things running on my laptop.)

so yeah. the start and end of the chain are expensive, and both are fairly constant cost. the intermediate versions have a relatively small linear coefficient, and we've done what we're aware of to make these builds do as little work as possible, but it's probably not small enough to be tenable as the distance between stable and what mrustc supports grows.
18:33:35
@whispers:catgirl.cloudwhispers [& it/fae] (actually i lied, we can probably cut off a minute and a half from each of the intermediate builds, but we don't feel like looking more into bootstrap right now. but other than that, i think shaving off any further time from the intermediate builds would require diving deeper into compiler flags and whatnot that might help.) 18:34:59
@whispers:catgirl.cloudwhispers [& it/fae] (actually i lied, we can probably cut off a minute and a half from each of the intermediate builds, but we don't feel like looking more into bootstrap right now. but other than that, i think shaving off any further time from the intermediate builds would require diving deeper into compiler flags and whatnot that might help (or you know. running on a faster machine).) 18:35:07
@whispers:catgirl.cloudwhispers [& it/fae] (actually i lied, we can probably cut off a minute and a half from each of the intermediate builds, but we don't feel like looking more into bootstrap right now. but other than that, i think shaving off any further time from the intermediate builds would require diving deeper into compiler flags and whatnot that might help. (or you know. running on a faster machine)) 18:35:16
@whispers:catgirl.cloudwhispers [& it/fae] so, we've been playing with rustc bootstrapping out of tree at https://codeberg.org/whispers/nebula/src/branch/meow/nix/pkgs/rust-bootstrap. the code itself is pretty bad, but we've got some initial performance metrics.

  • reference for build perf on my laptop: nom-build -A rustc-unwrapped --check on master: 1h52m17s

  • mrustc: 5m2s

  • minicargo: unused. i can't find a way to get it to apply the right flags while building, so it just gets built as part of the next step.

  • rust-1_90_0: 1h54m18s

* this is fully using mrustc's build system. i haven't tried to optimize it at all, but i suspect you could get at least a little better perf out of it with some work.
  • rust-1_91_1: 17m33s

  • rust-1_92_0: 18m53s

  • rust-1_93_1: 18m1s

  • rustc-1_94_0: 1h48m52s

* this is just rustc-unwrapped with .override { ... }, so this is the part we build right now in nixpkgs.

(take these as order of magnitude estimates, the numbers are extremely noisy. build were run on several different days with other things running on my laptop.)

so yeah. the start and end of the chain are expensive, and both are fairly constant cost. the intermediate versions have a relatively small linear coefficient, and we've done what we're aware of to make these builds do as little work as possible, but it's probably not small enough to be tenable as the distance between stable and what mrustc supports grows.
18:35:42
@whispers:catgirl.cloudwhispers [& it/fae] (actually i lied, we can probably cut off a minute and a half from each of the intermediate builds, but we don't feel like looking more into bootstrap right now. but other than that, i think shaving off any further time from the intermediate builds would require diving deeper into compiler flags with diminishing returns. (or you know. running on a faster machine)) 18:37:42
@whispers:catgirl.cloudwhispers [& it/fae] so, we've been playing with rustc bootstrapping out of tree at https://codeberg.org/whispers/nebula/src/branch/meow/nix/pkgs/rust-bootstrap. the code itself is pretty bad, but we've got some initial performance metrics.

  • reference for build perf on my laptop: nom-build -A rustc-unwrapped --check on nixpkgs master: 1h52m17s

  • mrustc: 5m2s

  • minicargo: unused. i can't find a way to get it to apply the right flags while building, so it just gets built as part of the next step.

  • rust-1_90_0: 1h54m18s

* this is fully using mrustc's build system. i haven't tried to optimize it at all, but i suspect you could get at least a little better perf out of it with some work.
  • rust-1_91_1: 17m33s

  • rust-1_92_0: 18m53s

  • rust-1_93_1: 18m1s

  • rustc-1_94_0: 1h48m52s

* this is just rustc-unwrapped with .override { ... }, so this is the part we build right now in nixpkgs.

(take these as order of magnitude estimates, the numbers are extremely noisy. build were run on several different days with other things running on my laptop.)

so yeah. the start and end of the chain are expensive, and both are fairly constant cost. the intermediate versions have a relatively small linear coefficient, and we've done what we're aware of to make these builds do as little work as possible, but it's probably not small enough to be tenable as the distance between stable and what mrustc supports grows.
18:40:11
@whispers:catgirl.cloudwhispers [& it/fae] * (actually i lied, we can probably cut off a minute and a half from each of the intermediate builds, but we don't feel like looking more into bootstrap right now. but other than that, i think shaving off any further time from the intermediate builds would require diving deeper into small things like compiler flags with diminishing returns. (or you know. running on a faster machine)) 18:51:30
@pyrox:pyrox.devdish [Fox/It/She]hmm, any reason why each end is so long? is it just because optimizations and rust being "like that"(tm)19:33:33
@pyrox:pyrox.devdish [Fox/It/She]would definitely be nice to reduce those as much as possible, especially 1.90 since that's bootstrapping-only19:33:54
@whispers:catgirl.cloudwhispers [& it/fae]the final step is a full stage 2 build which builds standard libraries for several targets, documentation, and several other things19:34:34
@pyrox:pyrox.devdish [Fox/It/She]why are we building std for several targets? is that so it can include wasm std, or is that something we could disable?19:35:09
@whispers:catgirl.cloudwhispers [& it/fae]wasm and bfpel-* something, yeah19:35:23
@whispers:catgirl.cloudwhispers [& it/fae] I'm not entirely sure why the mrustc end is slow, but i think it mostly boils down to the fact that it's a two stage build. the first stage is just building rustc with mrustc, but i think this makes stage 2 pretty slow because rustc is fairly reliant on optimizations, which mrustc doesn't do much of 19:36:38
@whispers:catgirl.cloudwhispers [& it/fae]but that's just my theory, i haven't looked into that side and there's a solid chance you could cut it down19:36:55
@whispers:catgirl.cloudwhispers [& it/fae]you could maybe amortize that cost across 1.90 and 1.91 by making "stage 2" just be building 1.91 (but you may be prone to miscompilation since mrustc isn't tested like that, i don't know)19:38:49
@pyrox:pyrox.devdish [Fox/It/She] okay you should be able to build without extra stdlibs by setting fastCross = true; in the final build derivation where you override rustc-unwrapped 19:39:51
@pyrox:pyrox.devdish [Fox/It/She]that also skips some other builds, quoting the code it "reuses the rustc from build"19:40:41
@whispers:catgirl.cloudwhispers [& it/fae]for comparison, each of the intermediate builds compiles six things: bootstrap, rustc, standard libraries, cargo, rust-installer, and generate-copyright (and I'll rip out those last two as soon as i next decide to look into it)19:40:37

Show newer messages


Back to Room ListRoom Version: 6