| 29 Jul 2022 |
profpatsch | building execline argv lists is already something like that | 18:26:27 |
infinisil | Ultimately it's specifying what happens at runtime with Nix 🤔 | 18:27:16 |
profpatsch | yeah, maybe even without noticing the border if you don’t want to | 18:27:45 |
profpatsch | maybe the border moves around flexibly in the background :P | 18:28:28 |
yorik.sar | We could so defer generation of builders from Nix by serializing not yet applied functions and creating derivations for builders. | 20:32:15 |
yorik.sar | * (null) | 20:32:27 |
| 30 Jul 2022 |
DavHau | In reply to @kevincox:matrix.org This strikes me as likely to add far more complexity than value. In what way would that add complexity? I think having clean interfaces between phases is a necessary step towards sanity. That would allow us to have real modularity of builds, where we can have reasonable assumptions about what will happen during a build, vs right now, for most users everything is a huge black box which is hard to debug. I'm also not worried about runtime performance. With the current bash based model, CPU cycles are wasted initializing an unnecessary amount of processes for simple operations like symlinking etc. If proper interfaces allowed us to implement build phases in the language that suits best for that phase, we will gain a lot of efficiency. Even if we have to run an extra process per phase the performance might be orders of magnitude better. | 09:41:58 |
Alyssa Ross | Processes are not created equal | 09:43:15 |
Alyssa Ross | (not disagreeing, just want to point out) | 09:43:26 |
Alyssa Ross | fork+exec overhead is trivial compared to e.g. interpreter startup time for most languages | 09:43:38 |
Alyssa Ross | so (just as an example) I'd expect you could run many lns before Python has started up | 09:44:16 |
Alyssa Ross | (especially statically linked, or rpath-optimised lns) | 09:44:55 |
DavHau | In reply to @qyliss:fairydust.space so (just as an example) I'd expect you could run many lns before Python has started up Good point. Having proper data on this might be interesting. I might do some benchmarks if I find time. | 10:03:31 |
DavHau | On the other hand. Performance is only then a concern when we talk about large numbers of of operations. And anything that doesn't launch processes will always be significantly faster in that scenario. | 10:19:08 |
Alyssa Ross | Those large numbers of operations tend to be contained in configure scripts / makefiles anyway | 10:20:16 |
Alyssa Ross | tbh I think optimising stdenv for speed is not going to be worth it | 10:20:43 |
Alyssa Ross | because I highly doubt anybody is bottlenecked on stdenv as opposed to the builds themselves | 10:21:02 |
Alyssa Ross | When I'm waiting hours for a build, it's not because stdenv is slow. | 10:21:18 |
DavHau | I agree. No need for optimization, but also no need to be worried about overhead in launching phases with proper interfaces. | 10:50:51 |
| Sandro 🐧 changed their display name from Sandro to Sandro 🐧. | 13:17:13 |
| 1 Aug 2022 |
| better_sleeping joined the room. | 09:11:58 |
| better_sleeping left the room. | 09:12:24 |
John Ericson | https://github.com/NixOS/nixpkgs/pull/183967 FYI here is example of some small low hanging cleanups, from the impromptu bootstrapping call | 14:50:48 |
John Ericson | not saying we can end up anywhere interesting with such baby steps alone, but it can be nice to go spelunking / do the archeology | 14:51:10 |
Wanja Hentze | In reply to @qyliss:fairydust.space fork+exec overhead is trivial compared to e.g. interpreter startup time for most languages side note: nix should probably not use fork+exec to spawn children, as it has a time overhead proportional to the amount of memory mapped by the parent process (which can be quite large in the case of Nix) you probably know this already, and maybe nix does it anyway. I just take any opportunity I can to shill posix_spawn - which does not have this problem. | 17:43:13 |
Wanja Hentze | In reply to @qyliss:fairydust.space fork+exec overhead is trivial compared to e.g. interpreter startup time for most languages * side note: nix should probably not use fork+exec to spawn children, as it has a time overhead proportional to the amount of memory mapped by the parent process (which can be quite large in the case of Nix) you probably know this already, and maybe nix does not even do this anyway. I just take any opportunity I can to shill posix_spawn - which does not have this problem. | 17:43:27 |
Wanja Hentze | shells like bash mostly still due it this way for cursed backcompat reasons but you can really do better | 17:45:20 |
Wanja Hentze | * shells like bash mostly still do it this way for cursed backcompat reasons but you can really do better | 17:45:27 |
Wanja Hentze |  Download Screenshot from 2022-08-01 19-45-36.png | 17:46:29 |
Wanja Hentze | old-ish graph from https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf | 17:46:50 |