Problem I’m trying to parallelize my time propagator and not seeing very encouraging results. A simple part is where I exponentiate a lot of independent operators using Crank–Nicolson: b_i = \exp(-\mathrm{i}\delta t h_i) a_i \Rightarrow b_i \approx \frac{I - \mathrm{i}\delta t/2 h_i}{I + \mathrm{…

Well, A and B are not sparse, they are dense matrices, nr by nl, and each pair of columns is associated with a separate complex-symmetric tridiagonal matrix h_i of dimension nr by nr.

Did you turn off BLAS threading? You can check it with BLAS.get_num_threads() and set it with BLAS.set_num_threads(1). Or just environment variable OMP_NUM_THREADS=1.

I don’t think BLAS is used here since the matrices are SymTridiagonal.

That should not matter since the multiplication and solve steps are not in BLAS, but in pure Julia: JuliaLang/julia/blob/b2d66c99672cdd726a8222335f39900f405b72f1/stdlib/LinearAlgebra/src/ldlt.jl#L169-L198 function ldiv!(S::LDLt{<:Any,<:SymTridiagonal}, B::AbstractVec…

I think an important thing for me to understand is the threading scheduler; is Threads.@threads no-thrills, plain even-distribution of work over available threads, like #pragma omp for in OpenMP? For this kind of problem, would FLoops.jl make a difference? Where can I expect overhead? I’ve gathered …

[image] jagot: is Threads.@threads no-thrills, plain even-distribution of work over available threads, Yes [image] jagot: Where can I expect overhead? You can potentially have some false sharing since you are writing to parts of memory on different threads that is close to each other.…

Interesting, but weird (all times faster, but slow-down instead of speedup with more threads): [image] However, I really need to store them as columns of dense matrices, for other parts of the propagator to work. I would be very interested if one can use the data locality to speed up the propagat…

FLoops.jl makes it easy to, e.g., re-use w in the same task but across different iterations. It could be a bit nicer for cache. But that’s really a micro-optimization and I’m not sure if’d matter. A sanity check you can do is to check the overhead of the task scheduling with @btime wait(@spawn noth…

That could very well be the case; if I run many steps of the propagator, and simultanously monitor using perf top -F 30 -r 0, I find this 28.52% [kernel] [k] acpi_idle_do_entry 18.84% libjulia-internal.so.1.7 [.] get_next_task 12.64% libjulia-internal.so.1.7 [.] jl_gene…

Do I understand it correctly that I am limited due to Threads.@threads using task-based parallelism instead of data parallelism, where the latter would be more applicable to my problem?

Parallelizing multiple Crank–Nicolson solvers

General Usage Performance

jagot March 13, 2021, 5:26am 22

This seems like a highly relevant discussion: Overhead of `Threads.@threads` - #29 by Elrod

Topic		Replies	Views
Parallelization in Julia vs C++ Performance question , parallel-computing	21	1088	March 11, 2026
Julia code becomes slower on running on supercomputers and does not scale well when parallelizing with Base.Threads Julia at Scale fortran , parallel , linearalgebra , threads	73	2907	January 22, 2024
Scaling of @threads for "embarrassingly parallel" problem Performance threads	29	2340	January 20, 2023
How to improve the scaling of Julia code aimed at multi-node parallelization? Julia at Scale linearalgebra , distributed	38	1064	August 14, 2024
Bad performances when using Multithreading and Distributed with heavy LinearAlgebra calculations Performance performance , multithreading , distributed	26	856	July 25, 2024

Parallelizing multiple Crank–Nicolson solvers

Related topics