Why CPU % reaches 80s when running julia code with no parallization?

General Usage
1

I have a julia code that consumes 34s (when using @time). I don’t have any parallelization in it (i.e., no parallel package is called nor directives) and nthreads()=1. However, when I check the task manager, I find that Julia.exe consumes 84% of the CPU which means that it runs all cores (the specifications of my system is as below).

julia> nthreads()
1
julia> versioninfo()
Julia Version 1.8.5
Commit 17cfb8e65e (2023-01-08 06:45 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 12 × Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-13.0.1 (ORCJIT, skylake)
  Threads: 1 on 12 virtual cores

Any reason for that? Does the code run on parallel?

2

Pure Julia will not multi-thread without your direction, but libraries Julia calls certainly can. Without knowing what code you ran, it’s difficult to answer why you’re seeing this.

My guess is that you have some linear algebra in your code. BLAS (to which Julia outsources most of its linear algebra) is multi-threaded by default. A couple of related functions:

julia> using LinearAlgebra

julia> BLAS.get_num_threads() # ask how many threads BLAS is using
6

julia> BLAS.set_num_threads(1) # set BLAS to run single-threaded
1 Like
3

Thank you very much for your feedback!.
My code is for the simulation of electrical systems by solving its linear equation 'Ax=bwhich calls SparseArrays, LinearAlgebra, ShiftedArrays, KLU, StaticArrayspackages. I setBLAS.set_num_threads(1)` and the CPU percentage did not reach 80%.

  • Are there packages (from the ones that I am using) that work on multi-threaded?
  • Is it always good to keep the default of these packages to work as multi-threaded?
4

SparseArrays has its own special variant of BLAS (I forget the name of it) specially made for sparse linear algebra and that is also likely multi-threaded. StaticArrays does not (as far as I know) multi-thread as it’s often detrimental at the small arrays sizes it deals with. I can’t speak for the others.

If you are already multi-threading your computation, it’s usually somewhat better to not have other packages multi-threading inside of those (too many schedulers fighting for CPU time). If you aren’t, then the defaults are probably great.

You can play with the thread counts, but in general I expect the defaults to work well. Definitely not worth spending much time on.

1 Like
5

Thanks for your great feedback.

I want to stop the multi-threading in SparseArrays. Do you know what is the directive for that (do similar similar job as `BLAS.set_num_threads(1))?

6

Sorry, I don’t. I spend a few minutes digging through SparseArrays and couldn’t find anything promising. Maybe someone else can point it out or maybe it’s not really accessible.

1 Like
7

Thank you very much for your feedback!

8

I do not think the SparseArrays code in general is multi threaded. Umfpack is, as is SuiteSparse, but I doubt that things like the matrix vector products and such are run in parallel.

2 Likes