| 26 Jun 2026 |
 emily | maybe we should have an openmpCheckPhaseHook that mpiCheckPhaseHook propgates then :P | 14:00:04 |
 Grimmauld (any/all) | but yeah, throwing it in propagatedNativeBuildInputs of numpy sounds like a plan a little less drastic than just throwing it in stdenv | 14:00:21 |
| emily | fwiw, OMP_NUM_THREADS turns up a surprising number of non-Python things | 14:00:25 |
| emily | looks like BLAS/LAPACK stuff. so maybe putting a hook in there is a good idea too. | 14:00:41 |
| Grimmauld (any/all) | Most of them link one of blas/lapack/libomp i'd guess? | 14:00:54 |
| emily | yeah I dunno. all that stuff is a mystery to me. there's llvmPackages.openmp too? | 14:01:08 |
| Grimmauld (any/all) | yeah | 14:01:16 |
| Grimmauld (any/all) | openmp gets compiled in, usually. Unless you do weird stuff :tm: and you can link it | 14:01:35 |
| Grimmauld (any/all) | and then there is boost that can optionally use omp/cuda too | 14:01:49 |
| Grimmauld (any/all) | its a whole mess | 14:01:57 |
| Grimmauld (any/all) | mpiCheckHook apparently defines the topology of the compute "cluster" to contain exactly one node (the nix builder), we can almost certainly skip that for just openmp things | 14:03:16 |
| Grimmauld (any/all) | Scientific computing is a mess. I hate it, despite it being technically my field outside nix... | 14:04:17 |
| Grimmauld (any/all) | propagatedNativeCheckInputs when | 14:06:23 |
| emily | huh, we don't have that? | 14:07:31 |
| emily | should be very harmless to propagate a hook like that unconditionally though | 14:07:49 |
| Grimmauld (any/all) | Yes, i agre | 14:09:00 |
 rntpts | gnu nproc respects cgroup limits since 9.8 (https://github.com/coreutils/coreutils/blob/57fe9ecd694459c44fa59b903d5dbb001f22ce66/NEWS#L531-L532) | 14:17:38 |
| Grimmauld (any/all) | * Yes, i agree | 14:09:03 |
 hexa | tools could be using all sorts of apis for guessing core count though | 14:18:02 |
| emily | CPU namespaces | 14:19:11 |
| rntpts | ninja does too | 14:19:28 |
 vcunat | Even if they didn't, they wouldn't be allowed by the kernel to use other cores. | 14:24:16 |
| vcunat | But fixed allocation of cores to builds doesn't seem ideal to me either way. | 14:24:42 |
| vcunat | * But fixed allocation of particular cores to particular builds doesn't seem ideal to me either way. | 14:24:52 |
| vcunat | (even if we tried some clever way of overlapping those sets) | 14:25:13 |
| rntpts | Yes they would. With default kernel config, cpu limits only apply if the system is overloaded. | 14:25:37 |
| rntpts | (Though that may be enough?) | 14:26:00 |
| vcunat | That sounds good to me. (I didn't find this in docs when I was looking years ago.) | 14:26:51 |
| rntpts | That also doesn't fix the overprovisioning of threads and memory that would happen. It would just ensure fair scheduling between jobs/derivations. So any scheduler contention would still exist for the tools that don't check cgroup limits themselves. | 14:29:41 |
 dramforever | openmp is for something like multi-processing (i can't immediately find the abbreviation expansion). mpi is "message-passing interface" | 14:32:16 |
