How to avoid BLAS thread oversubscription when using Threads.@spawn in Julia

TL;DR

Set BLAS.setnumthreads(1) once, before the parallel region, and never call it from inside concurrent tasks. BLAS (OpenBLAS or MKL) runs its own thread pool, independent of Julia's task scheduler. When your own tasks each trigger multithreaded BLAS, the two pools oversubscribe your cores and throughput drops.

Steps

1. Check the current BLAS thread count:

using LinearAlgebra
BLAS.get_num_threads()

Expected output: the number of physical cores, e.g. 8. If it prints 1, you are already single-threaded and there is nothing to fix.

2. Single-thread BLAS before spawning your own parallel work:

previous = BLAS.get_num_threads()
BLAS.set_num_threads(1)

Success check: BLAS.get_num_threads() == 1 returns true.

3. Run your parallel loop. A typical shape, with balanced chunks from ChunkSplitters.jl:

using Base.Threads
tasks = map(chunks) do ch
    @spawn begin
        for idx in ch
            # BLAS-backed work per item, e.g. factorisations, matmuls
            eval_model!(idx)
        end
    end
end
waitall(tasks)

Success check: wall-clock time is at or below the nested-parallel version, and BLAS.getnumthreads() still reports 1 after the loop.

4. Restore the previous setting when the parallel region is done:

try
    run_parallel()
finally
    BLAS.set_num_threads(previous)
end

Success check: BLAS.get_num_threads() == previous returns true, and a lone big matmul afterwards runs multithreaded again.

5. Benchmark both settings before committing. Oversubscription penalties depend on matrix size, core count, and BLAS vendor. Small matrices often win single-threaded BLAS plus Julia tasks; one huge matrix usually wins multithreaded BLAS alone.

When this applies

• Your own code is already parallel: Threads.@spawn, Threads.@threads, @distributed task loops.
• The tasks call BLAS-backed operations: * on matrices, mul!, lu, qr, svd, eig, cholesky, \.
• The run is CPU-bound on linear algebra with matrices big enough for thread startup to matter.

When this does not apply

• Single-threaded scripts doing one big matmul or factorisation: leave BLAS multithreaded, that is the fast configuration.
• GPU kernels via CUDA.jl or similar: BLAS thread counts are irrelevant there.
• Tasks that never touch BLAS: there is no second thread pool, so there is nothing to oversubscribe.
• Remote workers via Distributed.jl: BLAS.setnumthreads is per process, so set it on each worker with @everywhere instead of once on the driver.

Tool and version compatibility

Julia 1.9+ with the LinearAlgebra stdlib. Default BLAS vendor is OpenBLAS; some builds ship MKL. The setnumthreads call routes to the active vendor on both. Julia 1.8 and older behave the same, but thread-pool behaviour differs on the old scheduler.

Common variants

• "Julia BLAS oversubscription with multithreading"
• "should I set BLAS.setnumthreads(1) before Threads.@threads"
• "Julia OpenBLAS spawns too many threads in parallel code"
• "BLAS.setnumthreads race when called from multiple tasks"

Root cause

OpenBLAS and MKL maintain a thread pool per process that is completely separate from Julia's task runtime. With 8 Julia tasks and 8 BLAS threads each, up to 64 threads contend for 8 cores, and the lost time goes to context switching, cache thrashing, and locks inside BLAS. In addition, BLAS.setnumthreads writes one process-global value, so calling it concurrently from several tasks is a data race: the get/set/restore dance from the thread only works when it runs from a single thread outside the parallel region.

Edge cases

• Chunk size: splitting into equal index ranges can leave a tiny last chunk; use ChunkSplitters.jl or a work-stealing loop so no task idles. Use cld(n, nthreads) instead of ceil(Int, n / nthreads) to avoid float rounding surprises.
• waitall(tasks) is the current spelling; older foreach(wait, tasks) does the same.
• Tools like ThreadPinning.jl change how Julia threads map to cores; re-benchmark after pinning.
• If most of the time goes to non-BLAS work inside the tasks, the BLAS setting barely matters either way; measure before and after.

Resolved from public thread: https://discourse.julialang.org/t/using-threads-spawn-with-blas-set-num-threads/139865

Provenance

Resolved from the public thread: https://discourse.julialang.org/t/using-threads-spawn-with-blas-set-num-threads/139865

In Julia Discourse: "Using Threads.@spawn with BLAS.setnumthreads" (https://discourse.julialang.org/t/using-threads-spawn-with-blas-set-num-threads/139865): poster asks whether wrapping a Threads.@spawn frequency-sweep loop in BLAS.setnumthreads(1) has side effects; sgaure notes calling setnumthreads concurrently from tasks races on the process-global setting. Source: https://discourse.julialang.org/t/using-threads-spawn-with-blas-set-num-threads/139865