| 10 Aug 2024 |
 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 |
| emily | so the cases where it could make a big difference seem rather marginal. you'd need a completely non-generic function that is also a hotspot but not #[inline] annotated and that you cross over constantly in a tight loop | 20:11:06 |
| Randy Eckenrode | Linux may be more of an issue, but wasn’t there a desire to go PIE on Linux eventually? | 20:11:28 |
| emily | In reply to @emilazy:matrix.org
so the cases where it could make a big difference seem rather marginal. you'd need a completely non-generic function that is also a hotspot but not #[inline] annotated and that you cross over constantly in a tight loop and also I don't think the overhead is big enough that it would matter the vast majority of the time even in this case | 20:11:53 |
| emily | In reply to @reckenrode:matrix.org
Linux may be more of an issue, but wasn’t there a desire to go PIE on Linux eventually? (I hope so!) | 20:16:56 |
| emily | (I consider it shameful for PIE not to be default) | 20:17:02 |
| Randy Eckenrode | I think there’s some compatibility issues. | 20:17:26 |
| emily | that's what hardeningDisable is for | 20:17:33 |
| Randy Eckenrode | The only issue I can see with providing pre-built artifacts is whether it’s possible users could use a different version of Rust and cause things to explode. | 20:17:46 |
| Randy Eckenrode | * The only issue I can see with providing pre-built artifacts is whether it’s possible users could use a different version of Rust and cause things to break. | 20:17:54 |
| emily | I don't really see how, any more than they can use a different version of glibc | 20:19:30 |
| emily | I mean, I guess there is a sequence of contortions you could construct to mismatch things, but I don't think it'd be an easy mistake to make. | 20:19:49 |
| emily | (also I sort of expect Rust has some kind of compile-time checks for that, but I'm not sure.) | 20:20:00 |
 Alyssa Ross | I haven't caught up with the whole conversation, but no, Cargo goes out of its way to prevent you dropping in an rlib built elsewhere | 20:21:06 |
| Randy Eckenrode | Redacted or Malformed Event | 20:21:14 |
| Alyssa Ross | the only feasible way to do this is to reimplement cargo a la crate2nix | 20:21:27 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
I don't really see how, any more than they can use a different version of glibc There’s a couple of popular overlays outside of nixpkgs. My thinking is someone could use one of those get a Rust of a different version and then try to use the nixpkgs crate stuff to build an app, and it goes wrong. | 20:21:27 |
