| 3 Apr 2026 |
 emily | hmm are they? I feel like the average Windows ultrabook doesn't ship with 10 cores of anything but maybe I'm behind the times :) | 23:21:12 |
| emily | at the high end ofc is a different matter | 23:21:22 |
| emily | but direction there is very much towards clusters (e.g. there's RDMA over Thunderbolt now) | 23:21:42 |
 hexa | right, I'm probably comparing apples and oranges | 23:21:45 |
| emily | well tbh I guess with 5 + 5 you might get both using 4 P + 1 E which would be just fine | 23:22:44 |
| emily | er | 23:22:57 |
| emily | sorry I mean 2 P + 3 E | 23:23:06 |
| emily | what I mean is that M4 → M4 Pro looks like just 10 cores → 12 cores | 23:23:27 |
| hexa | oh, but it has many more P cores | 23:23:38 |
| hexa | I see | 23:23:39 |
| emily | but it's actually 4P → 8P, 6E → 4E | 23:23:40 |
| hexa | good call | 23:23:47 |
| emily | also higher memory bandwidth etc. | 23:23:48 |
| emily | so the perf differential may be higher than you expect | 23:23:53 |
| hexa | that changes things quite a bit | 23:24:09 |
| emily | I would be tempted to say you do one big-parallel build per M4 or else two per M4 Pro, say | 23:24:20 |
| emily | https://browser.geekbench.com/v6/cpu/compare/17442341?baseline=17440508 M4 vs. M4 Pro benchmark fwiw (though Nixpkgs is not Geekbench and also RAM differs) | 23:26:04 |
| emily | the memory bandwidth helps it eke out a bit more even on single-core workloads | 23:26:33 |
| hexa | I hear you | 23:27:46 |
 EsperLily [she/her] | is there any way to ask hydra to just try rebuilding a package that failed? something called edencommon failed on aarch64-darwin https://hydra.nixos.org/build/324463608 but the failure is just a timeout running tests, so it's a nondeterministic failure. The consequence of this is watchman now also needs to be built from source. Trying to build this stuff locally I also got the timeout failure, but I just tried to build edencommon on its own and it worked, so it'd be nice to have hydra just try again (and build watchman too) | 23:49:37 |
| hexa | restarted | 23:54:33 |
| 4 Apr 2026 |
| emily | that failure happens a lot, we have a patch to increase the timeout but I guess it's not enough now somehow | 00:19:07 |
| emily | someone should probably look into it. some package maintainer of the package. certainly not me. I would never maintain that awful stack | 00:19:24 |
| EsperLily [she/her] | wow i have no idea what's going on but after updating nixpkgs my locally-compiled Vim binary (part of the MacVim package) is crashing during startup. Stepping through with the vim debugger it crashes at func s:StarSetf(ft), and the crash appears to be a bounds check in strcpy. The MacVim package did not change at all, only its inputs changed. I've verified that running the old binary with the new vimrc works fine, and running the new binary with the old vimrc crashes, so it really is a change to the binary compilation. poking at this with nix-diff I see that llvm was updated, also ncurses, also stdenv itself seems to have been updated and bash but it's a little hard to figure out what's actually relevant. I don't suppose there's been any change recently that seems relevant here? | 01:00:22 |
| emily | my guess is something screwy with the weird Xcode/Nixpkgs toolchain mix that ~nothing else does | 01:09:20 |
| emily | either that or LLVM exposing some UB in old Vim code | 01:09:40 |
| emily | (looks like MacVim is lagging behind CVEs again https://github.com/macvim-dev/macvim/issues/1634) | 01:09:50 |
| emily | would probably need bisecting to say for sure what's going on but LLVM update seems like a solid bet | 01:10:26 |
 Randy Eckenrode | What version of LLVM? | 01:14:13 |
| Randy Eckenrode | Some of the earlier 21.1 releases had miscompilation issues on aarch64-darwin. | 01:14:35 |
