ParallelFor and ParallelChunks started fresh OS threads on every call, one per chunk,
through std::async. There are 57 call sites and several sit inside iterative fits, so
one run of the heaviest crystal created 13 497 threads and a 900-frame dataset 7 320.
Both now run on a persistent pool. The contracts are unchanged: ParallelChunks keeps
the same worker count and the same fixed split, so a reduction sums term for term as
before, and ParallelFor keeps stealing per item.
Two things in the pool are worth knowing. The caller is one of the hands - it claims
its own region's tasks and then waits only on tasks already running - so a region
entered from inside another region cannot deadlock at any depth, which a shared-queue
pool would. And a task wakes one worker rather than the whole pool: on a large machine
notify_all wakes every idle thread to find nothing, once per region, tens of thousands
of times a run.
Two hand-rolled copies of the same pattern now use it, in FrenchWilson and in the two
histogram passes of ComputeAsuGroups.
Be clear about what this buys today: nothing measurable. Thread creations drop 13 497
-> 770 and entering a parallel region goes from 1.2-2.2 ms to 112 us, an 11-20x cut,
but wall clock on 48 threads is level with before, inside the +-5 % this machine's
run-to-run placement is worth. What it removes is a cost that grows with the thread
count - measured, entry is linear in it - and the machine this is heading for has four
times the threads of the one it was measured on, where the same 335 regions a run
would cost about 1.8 s of pure thread creation.
ComputeAsuGroups' histogram also changes. It is an nthreads x n_groups table, 936 MB
at -N 48 on the heaviest crystal and allocated five times a run, and the prefix over
it walked DOWN a column - a 19.5 MB stride, so a cache and TLB miss per step, 234 M of
them, serially. Both passes now walk rows and split over group ranges. The counts are
integers, so the result is bit-identical. This one is reasoning, not measurement: at 48
threads it sits under this machine's noise and could not be shown either way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
