Document Numba/OMP_NUM_THREADS oversubscription alongside FFT threading

[pzeiger]

Summary

The "Set internal thread parallelization" section already covers oversubscription between Dask's chunk-level parallelism and FFTW/MKL's own per-transform threading. The same risk applies to Numba: the real-space multislice algorithm, and a few other CPU-only code paths, use Numba's own thread pool rather than the fftw.threads/mkl.threads knobs already documented, controlled instead by OMP_NUM_THREADS (or NUMBA_NUM_THREADS directly, which takes precedence) since abTEM/abTEM#441.

Adds one paragraph to that same section rather than a new one, since it's the same underlying principle stated for a different library.

What it says

• Numba's thread pool follows OMP_NUM_THREADS if set, or every visible core otherwise; NUMBA_NUM_THREADS overrides independently.
• These kernels are memory-bandwidth-bound and scale poorly past a handful of threads even for one isolated computation — a large value rarely helps, so benchmark rather than assuming the full core count is best.
• Once Dask is already running many chunks concurrently, keeping the per-kernel thread count low costs nothing at worst and can measurably help — once the worker count exceeds the physical core count, extra internal threads per kernel add contention rather than finding anything left to parallelize into.

🤖 Written by Claude Code — Paul reviewed and posted it