```julia -t``` Does not respect the number of threads

Specific Domains Numerics
1

Hi all,

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.

Thanks a lot

2

How did you install julia? The suggested way is to use juliaup.

Can you share the output of

versioninfo()

on both machines?

3

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)
4

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

LinearAlgebra.BLAS.get_num_threads()
LinearAlgebra.BLAS.set_num_threads()

shed any further light on this?

5

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?

6

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

7

Thanks. It would be great, I think, to have such a possibility. Maybe we can raise the issue?

8

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.

9

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

10

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.

1 Like
11

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()

12

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

13

  • 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.

3 Likes
14

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.

1 Like