!djTaTBQyWEPRQxrPTb:nixos.org

Nixpkgs Architecture Team

236 Members
https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture52 Servers

Load older messages


SenderMessageTime
29 Jul 2022
@profpatsch:augsburg.oneprofpatschbuilding execline argv lists is already something like that18:26:27
@infinisil:matrix.orginfinisilUltimately it's specifying what happens at runtime with Nix 🤔18:27:16
@profpatsch:augsburg.oneprofpatschyeah, maybe even without noticing the border if you don’t want to18:27:45
@profpatsch:augsburg.oneprofpatschmaybe the border moves around flexibly in the background :P18:28:28
@yorik.sar:matrix.orgyorik.sarWe could so defer generation of builders from Nix by serializing not yet applied functions and creating derivations for builders.20:32:15
@yorik.sar:matrix.orgyorik.sar * (null) 20:32:27
30 Jul 2022
@hsngrmpf:matrix.orgDavHau
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
@qyliss:fairydust.spaceAlyssa RossProcesses are not created equal09:43:15
@qyliss:fairydust.spaceAlyssa Ross(not disagreeing, just want to point out)09:43:26
@qyliss:fairydust.spaceAlyssa Rossfork+exec overhead is trivial compared to e.g. interpreter startup time for most languages09:43:38
@qyliss:fairydust.spaceAlyssa Ross so (just as an example) I'd expect you could run many lns before Python has started up 09:44:16
@qyliss:fairydust.spaceAlyssa Ross (especially statically linked, or rpath-optimised lns) 09:44:55
@hsngrmpf:matrix.orgDavHau
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
@hsngrmpf:matrix.orgDavHauOn 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
@qyliss:fairydust.spaceAlyssa RossThose large numbers of operations tend to be contained in configure scripts / makefiles anyway10:20:16
@qyliss:fairydust.spaceAlyssa Rosstbh I think optimising stdenv for speed is not going to be worth it10:20:43
@qyliss:fairydust.spaceAlyssa Rossbecause I highly doubt anybody is bottlenecked on stdenv as opposed to the builds themselves10:21:02
@qyliss:fairydust.spaceAlyssa RossWhen I'm waiting hours for a build, it's not because stdenv is slow.10:21:18
@hsngrmpf:matrix.orgDavHauI agree. No need for optimization, but also no need to be worried about overhead in launching phases with proper interfaces.10:50:51
@sandro:supersandro.deSandro 🐧 changed their display name from Sandro to Sandro 🐧.13:17:13
1 Aug 2022
@better_sleeping:converser.eubetter_sleeping joined the room.09:11:58
@better_sleeping:converser.eubetter_sleeping left the room.09:12:24
@Ericson2314:matrix.orgJohn Ericsonhttps://github.com/NixOS/nixpkgs/pull/183967 FYI here is example of some small low hanging cleanups, from the impromptu bootstrapping call14:50:48
@Ericson2314:matrix.orgJohn Ericsonnot saying we can end up anywhere interesting with such baby steps alone, but it can be nice to go spelunking / do the archeology14:51:10
@whentze:matrix.orgWanja 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
@whentze:matrix.orgWanja 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
@whentze:matrix.orgWanja Hentzeshells like bash mostly still due it this way for cursed backcompat reasons but you can really do better17:45:20
@whentze:matrix.orgWanja Hentze * shells like bash mostly still do it this way for cursed backcompat reasons but you can really do better17:45:27
@whentze:matrix.orgWanja HentzeScreenshot from 2022-08-01 19-45-36.png
Download Screenshot from 2022-08-01 19-45-36.png
17:46:29
@whentze:matrix.orgWanja Hentzeold-ish graph from https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf17:46:50

Show newer messages


Back to Room ListRoom Version: 9