| 29 Oct 2024 |
connor (burnt/out) (UTC-8) | I don't know enough CPP to know if you're kidding lmao | 17:34:31 |
K900 | That's the rule for all C++ code | 17:35:37 |
Bryan Honof | Redacted or Malformed Event | 18:49:16 |
Bryan Honof | Wrong channel, sorry. 🙃 | 18:54:38 |
| eva changed their profile picture. | 22:26:41 |
| 30 Oct 2024 |
connor (burnt/out) (UTC-8) | Design-wise, why does so much of libexpr take in pointers, mutate state, and return void? Is this "the way" interpreters or state management should be implemented when using C++? To be clear, not criticizing! Just wanted to check if this pattern is one that just happened over the evolution of the codebase, is known to be a good way to do the implementation, or something else. | 00:19:11 |
| Lach joined the room. | 00:25:02 |
emily | it's a codebase from 2003 :) | 00:25:15 |
emily | trying to infer any kind of best practice from the Nix code can only lead to madness, I think. it is the way it is because it is the way it is. it's research code that has survived 20 years | 00:25:49 |
tomberek | The lazy evaluation of thunks is represented by mutation of a Value. This way pointers to it remain valid. This also allowed for using boehmgc to do GC. This is the remnants of an evaluation method that worked okay when Nixpkgs was far smaller and had far fewer layers of abstraction.
A new evaluation engine would be interesting. Some people discussed this a bit at NixCon (@flokli ), but implementing it and showing an actual speedup remains to be done. | 00:36:04 |
tomberek | I'd love to see if this provides any benefit. Not sure how much effort it would be to run a test. | 00:40:50 |
connor (burnt/out) (UTC-8) | Alrighty, this is as far as I've gotten: https://github.com/NixOS/nix/pull/11767 It builds in a shell (not all the tests pass, though I guess you could use nix build -L .#hydraJobs.buildNoTests.x86_64-linux?) and I used it to build hello world. Haven't done any investigation into performance because I think that'd be premature (but anyone is welcome of course). | 01:25:10 |
tomberek | I specifically suspect that the update operator for attrs would benefit from such persistence. | 01:51:26 |
tomberek | (There are lots of instances of large attrsets in Nixpkgs being appended to.) | 01:52:02 |
magic_rb | This is interesting, i am definitely looking forward to any progress on this front | 02:32:52 |
connor (burnt/out) (UTC-8) | I've got the attention of a goldfish and split my time with maintaining CUDA packaging so expect progress to be sporadic ;) | 02:42:24 |
| wesfun joined the room. | 04:16:56 |
connor (burnt/out) (UTC-8) | Alrighty, I can at least eval my nixos config now. It's slower right now, though I'm almost certain that's because I can't figure out how to use transient without values being GC'd in the interim. The code is also super naive and I'm sure can be improved greatly. But it's a start! | 07:29:23 |
| seapat left the room. | 07:49:47 |
| Philipp Jungkamp joined the room. | 11:57:32 |
Mic92 | connor (he/him) (UTC-7): how much slower? | 13:30:08 |
Mic92 | 2x, 10x? | 13:30:22 |
Mic92 | For NixOS I would also expect that we have more attrsets rather than lists. | 13:31:36 |
connor (burnt/out) (UTC-8) | Added numbers at the top of the PR (see Early numbers). Looks like a slowdown of about 12%. | 16:58:43 |
| Paul joined the room. | 23:38:54 |
| 31 Oct 2024 |
Mic92 | connor (he/him) (UTC-7): ok. I could imagine that it takes more cpu time to lookup those nested datastructure (i.e. pointer chasing). I suppose you didn't look at memory usage in comparison? | 13:17:32 |
Mic92 | I added some environment variables to the pull request to check for it. | 13:17:47 |
| .. joined the room. | 15:39:09 |
.. | Hi, Is there a way to talk with Nix Core maintainer (or Dependency Resolution Specialist)? | 15:40:48 |
K900 | ElaboratE? | 15:47:11 |