11 Oct 2024 |
jakehamilton | Relatedly, I was curious about the feasibility of memoization for calls since a large amount of function calls for the module system end up being duplicated. | 14:54:09 |
K900 | Generally I don't think it's really a good solution because we don't even know what the bottlenecks are most of the time | 14:54:10 |
jakehamilton | In reply to @k900:0upti.me cppnix has an experimental branch that does that for not very large gains Ah, gotcha. I think nix-eval-jobs was mentioned as something that tries to multithread, but haven't seen or used anything for common use cases. | 14:55:00 |
K900 | nix-eval-jobs is not multithreaded inside a single eval | 14:55:17 |
jakehamilton | In reply to @k900:0upti.me nix-eval-jobs is not multithreaded inside a single eval I see, that tracks with what my gut was telling me. Thank you for the clarification! | 14:55:50 |
Tristan Ross | I've benchmarked the multithreaded evaluator quite a bit between single core and 64 cores, at some point, the performance degrades because it seems there's just not enough jobs available for the limit. | 15:04:32 |
Tristan Ross | It's kinda interesting because with a nix flake check, it seems to depend on the number of attributes on the outputs attr set | 15:05:18 |
aloisw | Don't they only evaluate different outputs in parallel? | 16:04:17 |
KFears (tragedy arc) | In reply to @k900:0upti.me Generally I don't think it's really a good solution because we don't even know what the bottlenecks are most of the time Really handy that OTLP is interested in merging profiling: https://github.com/open-telemetry/oteps/blob/main/text/profiles/0239-profiles-data-model.md | 16:14:10 |
KFears (tragedy arc) | https://github.com/open-telemetry/opentelemetry-cpp/issues/2657 | 16:19:19 |
K900 | Yeah probably won't help us much, the real problem is mapping evaluator spans back to Nix code | 16:20:39 |
KFears (tragedy arc) | Grafana Pyroscope has profiles-to-traces, which can help a bit | 16:23:00 |
KFears (tragedy arc) | But it's a hard problem with solutions that didn't even hit bleeding edge yet, for sure | 16:23:27 |
KFears (tragedy arc) | I wonder if it's possible to get NixLang to support OTLP tracing. Would be possible to track spans across Nix/C++ boundary... | 16:29:40 |
12 Oct 2024 |
| Kevin Tran joined the room. | 00:11:47 |
Kevin Tran | Download 8nmaa2n1msjbik2cdwdknmyz26jk2iwl-lix-2.91.0.txt | 00:13:44 |
Kevin Tran | i was update my flake.lock and rebuilding with darwin-rebuild, when i got this error message. i am running macos sequoia | 00:13:59 |
| Federico Damián Schonborn changed their profile picture. | 00:30:56 |
Tristan Ross | In reply to @aloisw:kde.org Don't they only evaluate different outputs in parallel? Yeah, each output takes a job which I think is where this sort of causes the performance degradation after a certain number of cores being made available. | 02:05:15 |
julia | I mean also my understanding is the implementation was just mutexes everywhere... (... a custom implementation for the quoted reason of not wanting to use mutexes, except they reimplemented the whole worker thread waiting but in userspace) | 02:44:15 |
julia | * I mean also my understanding is the implementation was just mutexes everywhere... (... a custom implementation for the quoted reason of not wanting to use mutexes, except they reimplemented the whole worker thread waiting but in userspace and used CAS i.e. mutex) | 02:45:22 |
K900 | It's a new, uniquely cursed form of synchronization primitive | 06:34:05 |
K900 | An eetex | 06:34:08 |
aloisw | Custom mutex implemented using mutexes, to be precise. | 07:56:02 |
| @eida:techniverse.net joined the room. | 08:46:08 |
| @eida:techniverse.net left the room. | 08:51:28 |
uep | why has noone invented the µtex | 10:09:41 |
antifuchs | In reply to @k900:0upti.me An eetex The small, less threatening variant would be the moo-dengtex? | 12:04:08 |
KFears (tragedy arc) | DetSystex | 12:23:02 |
qbit | trying to get my darwin-aarch64 machine over the nix->lix bump | 14:08:27 |