I am running some large-scale multithreading numerical code on a couple of different servers. In one of them (and only in one) I am seeing that the machine does not obey the restriction on the number of threads to be used. I am using the following command
nohup julia -t 40 name_of_file.jl &
while it tends to use all the available threads no matter the number of threads that I put under the flag -t
Since this is happening only on one machine, can you tell me which features of the machine I should check against the other machines?
I am using on both servers julia v1.11.1, one server is using fedora distribution, while the other (presenting this error) is using fedora server distribution.
Yes, I installed using juliaup on both machines. I have to say that the problem remained after upgrading the julia version from 1.11.1 to 1.11.5. Notice that I am running the script with the flag ```âprojectâââ. therefore, I suspect that the julia version is quite irrelevant.
Anyway, this is the output that I get on the problematic machine
Julia Version 1.11.5
Commit 760b2e5b739 (2025-04-14 06:53 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 256 Ă AMD EPYC 7762 64-Core Processor
WORD_SIZE: 64
LLVM: libLLVM-16.0.6 (ORCJIT, znver2)
Threads: 1 default, 0 interactive, 1 GC (on 256 virtual cores)
while this is the output on the ``goodââ machine
Julia Version 1.11.5
Commit 760b2e5b739 (2025-04-14 06:53 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 128 Ă AMD EPYC 7502 32-Core Processor
WORD_SIZE: 64
LLVM: libLLVM-16.0.6 (ORCJIT, znver2)
Threads: 1 default, 0 interactive, 1 GC (on 128 virtual cores)
Although -t specifies how many threads Juliaâs multithreading can use, there may also be separate multithreading going on in external libraries, such as BLAS. Can
seems a good idea! I checked with BLAS and indeed improves. Do you know if there is a way to set the number of threads for ALL the libraries in a single command?
I donât think there is such way. My advice is to study the libraries you are using and check for that info beforehand.
Julia internally use other libraries which have other variables to set the number of threads used. Even the example above of
LinearAlgebra.BLAS.set_num_threads()
Would have a different behavior depending on which vendor you are using for blas libraries. For example, in OpenBLAS it would set the threads for both blas and lapack routines, while in MKL only the blas routines would be affected
But where would you want to raise such an issue? Julia cannot know which libraries you are using. And library authors all have their own conventions, in particular if they are not using Julia threads but OS threads.
Sorry, I should have been more specific. I have no idea if and how such a situation can be handled. My idea, roughly speaking, would be the following:
Whenever I run a script with a prescription on the number of threads, I would love that the program overwrites any other variables with this number of threads. But again, I understand that such a procedure is not possible perhaps
I mean, for BLAS and MKL this might be possible. But I donât think that will be implemented, because there are people who actually want to run Julia with one thread and BLAS with 16 threads.
Are there any other major libraries that use threads? It seems to me that there are generic Julia multithreading by -t and then BLAS/Lapack multithreading by either OpenBLAS or MKL. Thatâs not really a lot of permutations and it could be possible to just set the threads based on -t, especially if we have generic set_num_threads()
Perhaps one could consider two types of -t flags: one that overwrites other thread variables and one that does not overwrite. This option would cover all situations, I guess
OpenMP-based libraries: Packages that wrap C/C++ libraries using OpenMP (such as some FFT, image processing, or numerical libraries) will use threads managed by OpenMP, not Julia.
External C/C++ integration (e.g., CxxWrap.jl): Libraries that integrate with C++ via CxxWrap.jl can expose C++ libraries that start and manage their own threads. With Julia 1.9 and later, Julia can âadoptâ external threads, allowing C++ code to call into Julia from non-Julia threads, but the threads themselves are still managed by the external environment
ZMQ.jl: This package, which wraps the ZeroMQ messaging library, can use its own threads for network communication and message handling
Other C libraries: Any Julia package that wraps a C library which internally uses pthreads or other native threading APIs will be using non-Julia threads.
Key point: These threads are not visible to Juliaâs thread scheduler and are not managed by Juliaâs Threads.@threads or similar mechanisms. This separation can lead to complex interactions, especially regarding thread safety and resource contention.
If any of these libraries are âmajorâ libraries is hard to decide. But because all of these libraries can exists and are outside of the influence of the Julia developers, I donât think they will add any option for this (unknown) set of libraries to Julia itself.
I think that Julia canât, and shouldnât, manage other libraries threads, each library should be responsible for its own threads.
The -t option only lets you manage threads used in pure Julia code, maybe we could ask to further remark this in the documentation, but again, Julia canât take responsibility on managing third libraries settings.