| 10 Aug 2024 |
 emily | ok, I will check if it is that simple :) | 14:32:04 |
| emily | I'm used to habitually skipping over CI changes when checking PRs for Nixpkgs, bad habit. | 14:32:35 |
| emily | …but then why do tests pass on aarch64-linux??? | 14:33:48 |
| emily | ohh | 14:34:34 |
| emily | doCheck = !stdenv.isAarch64 && !stdenv.isDarwin;
| 14:34:42 |
| emily | 🤪 | 14:34:45 |
 Alyssa Ross | ohhh | 14:56:21 |
| emily | I'm working on testing it now | 14:58:10 |
| emily | I suspect we might be able to run the checks now | 14:58:15 |
| emily | (on those platforms) | 14:58:21 |
| emily | btw, PSA for anyone interested: https://github.com/NixOS/nixpkgs/issues/333702 | 14:58:29 |
| emily | Alyssa Ross: you said that the individual crates would have to be essentially source packages because of Cargo's demands, but is that really true? I don't know how much compilation time it'd actually save us, but we could compile libraries as rlibs, couldn't we? hell, I think we could even get away with dylib – ABI compatibility doesn't matter to us given the whole Nix thing | 19:40:11 |
| emily | I think there is at least one other distro that dynamically links Rust crates (Fedora?) | 19:41:24 |
| emily | I guess there is the potential issue of packages that support multiple major SemVer versions getting locked to different things at dependency resolution time 🤔 | 19:43:17 |
| emily | though I think that would apply to your scheme in general | 19:43:24 |
| emily | and can probably be avoided with Cargo.lock generation | 19:43:38 |
 purepani | Wouldn't dynamically linking potentially lose out on some compiler optimizations? Doubt it's super important, but I maybe good to keep in mind | 19:45:38 |
 Randy Eckenrode | Wouldn’t that only matter for LTO, which crates have to opt into using? I know there’s a startup penalty for dynamic linking, but is there any other penalties? Darwin is PIE, so there’s no avoiding that by using static archives. | 20:06:33 |
| Randy Eckenrode | * Wouldn’t that only matter for LTO, which crates have to opt into using? I know there’s a startup penalty for dynamic linking, but is there any other penalties? Darwin is PIE, so there’s no avoiding the overhead of that by using static archives. | 20:07:00 |
| Randy Eckenrode | * Wouldn’t that only matter for LTO, which crates have to opt into using? I know there’s a startup penalty for dynamic linking, but are there any other penalties? Darwin is PIE, so there’s no avoiding the overhead of that by using static archives. | 20:07:20 |
| Randy Eckenrode | * Wouldn’t that only matter for LTO, which crates have to opt into using? I know there’s a startup penalty for dynamic linking, but are there any other penalties? Darwin is PIE, so there’s no avoiding the overhead of position-independence/ASLR by using static archives. | 20:07:33 |
| Randy Eckenrode | * Wouldn’t that only matter for LTO, which crates have to opt into using? I know there’s a startup penalty for dynamic linking, but are there any other penalties? Darwin is PIE, so there’s no avoiding the overhead of position-independence by using static archives. | 20:07:37 |
| emily | cross-crate inlining only happens with explicit #[inline] annotations and I believe that the source for those goes into the rlib files(? not sure) | 20:08:21 |
| emily | (also not sure if it applies to dynamic linking) | 20:08:25 |
| emily | In reply to @reckenrode:matrix.org
Wouldn’t that only matter for LTO, which crates have to opt into using? I know there’s a startup penalty for dynamic linking, but are there any other penalties? Darwin is PIE, so there’s no avoiding the overhead of position-independence by using static archives. AIUI there's an indirection penalty on every function call by default because of bad Linux platform decisions I believe, but like, it applies to everything we build in Nixpkgs, and we could fix that without switching away from dynamic linking if we wanted | 20:09:41 |
| emily | I suspect most hot spots probably don't involve tight loops around calls that cross crates but aren't inlined | 20:10:04 |
| emily | if you remember how generics in Rust work | 20:10:11 |
| emily | none of that stuff is going to be a dynamically loaded function call | 20:10:18 |
| emily | it'll be expanded right into the resulting executable | 20:10:31 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
AIUI there's an indirection penalty on every function call by default because of bad Linux platform decisions I believe, but like, it applies to everything we build in Nixpkgs, and we could fix that without switching away from dynamic linking if we wanted I don’t know about Linux, but a static archive can be relinked into a dylib on Darwin. I do it in the MoltenVK derivation. Darwin is PIE, so wouldn’t you pay that penalty regardless? PIE can’t even be disabled on aarch64-darwin, and if you try to be sneaky with assembly, the linker will fail with an error if it finds instructions using absolute addressing. | 20:11:02 |
