| 26 Jun 2026 |
 emily | there's some logic somewhere that caps it to 64 | 16:40:05 |
| emily | not sure why | 16:40:07 |
| emily | I also saw one package dividing it (maybe because parallel processes using OpenMP or something?) | 16:40:20 |
 hexa | lmao | 16:40:29 |
| hexa | some set it to $NIX_BUILD_CORES | 16:40:48 |
| emily | export OMP_NUM_THREADS=$(( $NIX_BUILD_CORES / 4 ))
if [ $OMP_NUM_THREADS -eq 0 ]; then
export OMP_NUM_THREADS=1
fi
| 16:40:52 |
| hexa | so they have to check if that is 0 | 16:40:55 |
| hexa | I have a part in that | 16:41:02 |
| hexa | feel free to blame | 16:41:05 |
| emily | and NumPy and SciPy do export OMP_NUM_THREADS=$((NIX_BUILD_CORES > 64 ? 64 : NIX_BUILD_CORES)) | 16:41:11 |
| emily | which, how does that handle the 0 case actually | 16:41:24 |
| hexa | not | 16:41:31 |
| emily | oh SciPy does the division+check, NumPy doesn't | 16:41:37 |
 Grimmauld (any/all) | numpy tests quite quickly, even with OMPNUMTHREADS=1 | 16:41:40 |
| hexa | https://github.com/OpenMathLib/OpenBLAS/issues/2993 | 16:41:41 |
| hexa | https://gitlab.freedesktop.org/pixman/pixman/-/work_items/62 | 16:41:51 |
| emily | then how come NumPy 2 builds 🤔 | 16:42:03 |
| emily | oh right | 16:42:05 |
| emily | iirc Nix and Lix never actually set it to 0 in practice in the build sandbox these days? | 16:42:13 |
| emily | since it gets autodetected | 16:42:18 |
| hexa | https://github.com/OpenMathLib/OpenBLAS/pull/5808 🤔 | 16:42:28 |
| hexa | Redacted or Malformed Event | 16:42:31 |
| hexa | oh, possible | 16:42:40 |
| emily | but the things that divide it need to take into account that rounding down to 0 | 16:43:14 |
| hexa | I hope we're killing all of that | 16:43:34 |
| Grimmauld (any/all) | https://github.com/NixOS/nixpkgs/pull/535725
have fun | 16:44:19 |
| emily | we should probably default to $NIX_BUILD_CORES? | 16:44:52 |
| hexa | hell no | 16:45:01 |
| hexa | OMP threads are on top of NIX_BUILD_CORES already | 16:45:15 |
| Grimmauld (any/all) | you'd be multiplying^^ | 16:45:31 |
