[email protected] is slower than [email protected] #403
Comments
|
Can you please post the full output of each run, with the timing statistics. Also, what is the output of |
and after restarting julia As you see the time is spent in the factorization and the backsolve steps of the optimizer. This is MUMPS LDL^T factorization phase and MUMPS backsubstitution phase. The symbolic phase runtime performance has not change. But the factorization and backsubstitution phases have and therefore the problem may be related to the BLAS library MUMPS is compiled with. Is it possible that MUMPS is shipped with Vanilla BLAS statically compiled in? By the way I am running on WSL Linux Ubuntu 22.04 but I experience the same problem on the MAC M1 Pro of a colleague. In his case using Ipopt v1.6.0 the time needed was 7.6 seconds and with Ipopt v1.5.1 the time was 3.4 seconds. |
Can you provide this? How did you install Julia? Since the time is dominated by the linear system solve, there's not much to fix on our end. The traces are not identical, so it isn't surprising that the runtimes might differ. This could just be luck, or some small change in numerical handling in MUMPS, or really anything. You could try a different linear solver: Or swap the BLAS library: cc @amontoison |
|
It cannot be due to MUMPS 5.6.2 because I have compiled it myself and I am using it on another application and there is no problem there. It is linked against Intel's OneAPI MKL and I have the same running times with all MUMPS versions on my application C++ based. I do not know what the Julia MUMPS or Ipopt package are doing with the BLAS. You do not need to check the thats it. |
|
I can reproduce, but I don't know what we can or should do about it. @amontoison is the expert. julia> versioninfo()
Julia Version 1.10.0
Commit 3120989f39b (2023-12-25 18:01 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: macOS (x86_64-apple-darwin22.4.0)
CPU: 8 × Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, skylake)
Threads: 1 on 8 virtual coresScriptimport PowerModels, Ipopt, PGLib
PowerModels.solve_ac_opf(
PGLib.pglib(PGLib.find_pglib_case("3012")[1]),
Ipopt.MOI.OptimizerWithAttributes(Ipopt.Optimizer, "print_timing_statistics" => "yes"),
)Manifest diff1.6.0(pglib) pkg> st -m
Status `/private/tmp/pglib/Manifest.toml`
[b6b21f68] Ipopt v1.6.0
[9cc047cb] Ipopt_jll v300.1400.1303+0
[d7ed1dd3] MUMPS_seq_jll v500.600.200+0
⌅ [319450e9] SPRAL_jll v2023.11.15+01.5.1(pglib2) pkg> st -m
Status `/private/tmp/pglib2/Manifest.toml`
⌃ [b6b21f68] Ipopt v1.5.1
⌅ [9cc047cb] Ipopt_jll v300.1400.1302+0
⌅ [d7ed1dd3] MUMPS_seq_jll v500.600.100+0
⌅ [319450e9] SPRAL_jll v2023.8.2+0There are no obvious culprits to Ipopt.jl: Ipopt_jll is built slightly differently: The Main difference is the new MUMPS version: https://github.com/JuliaPackaging/Yggdrasil/pull/7559/files There are a few minor changes to coin-or/Ipopt, but nothing obvious: coin-or/Ipopt@1e0a5df...4262e53 TimingMain culprit is 1.6.01.5.1SPRALI cannot reproduce with SPRAL, so this is likely a MUMPS issue. import PowerModels, Ipopt, PGLib
PowerModels.solve_ac_opf(
PGLib.pglib(PGLib.find_pglib_case("3012")[1]),
Ipopt.MOI.OptimizerWithAttributes(Ipopt.Optimizer, "print_timing_statistics" => "yes", "linear_solver" => "spral"),
)Julia 1.9Can also reproduce. |
odow
changed the title
|
Can you provide the timing if you switch the BLAS / LAPACK backend with a |
|
More or less exactly the same timing: julia> LinearAlgebra.BLAS.lbt_get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries:
├ [ LP64] Accelerate
└ [ILP64] Accelerate1.6.0 1.5.1 |
|
I can verify that my application which is C++ based has the same running time performance with both MUMPS 5.6.1 and 5.6.2 versions. Just rechecked it. I am using OneAPI MKL BLAS on Linux. I can also verify that in Julia switching the BLAS to MKL does not change essentially anything. The slow down for MUMPS 5.6.2 is consistent and only for MUMPS. Both 1.6.0 and 1.5.1 versions of Ipopt with HSL have the same runtime performance. It is only MUMPS 5.6.2 that is problematic. |
|
I added some OpenMP flags when I compiled MUMPS 5.6.2. Update: I quickly checked with |
|
In all my tests OMP_NUM_THREADS=1 from the shell. Usually an OMP-parallel code slows down the higher the number of threads due to wrong parallel directives or design not appropriate for OMP (memory not copied for each thread etc). As far as I know MUMPS is MPI parallel and not OMP parallel. Correct me please if I am wrong. I am always linking against the sequential mpi library. Furthermore, SPRAL is much slower than MUMPS and slower than HSL libraries. It relies on this hwlock library that nobody knows for sure what it offers, and even when it uses a powerful GPU it is still slower than MA57 or MA97 for large problems. It also requires particular environmental variables to be exported by the user and I cannot see where and how we could benefit from it when in academia we can use for research purposes HSL libraries that are more reliable and much faster without the GPU and ENV hassle. |
|
Do you compile MUMPS with SPRAL was developed by Jonathan Hogg, but he left the HSL team 10 years ago. Yes, HSL is more efficient and easy to use. |
|
I did not know MUMPS was OMP capable. I was hoping it to be at some point, but because I noticed MPI and libmpiseq I was under the impression that it was only MPI parallel. It is good to know that it can OpenMP. I will give it a try. I recompiled MUMPS 5.6.2 with -fopenmp and linked with -fopenmp. I set OMP_NUM_THREADS=6 and so the same running time as the sequential code. So I guess it is not OMP aware. |
|
Hi guys, |
|
Thanks @DoctorDro! I recompile MUMPS with Yggdrasil now. |
|
Very weird. Thanks for digging deep into this @DoctorDro |
|
Just FYI, |
|
@DoctorDro |
amontoison
added a commit
to amontoison/Ipopt.jl
that referenced
this issue
Feb 1, 2024
close jump-dev#403 Ipopt v3.14.13 -> v3.14.14 Bump the version of SPRAL Fix the problem with OpenMP for MUMPS 5.6.2
Merged
|
@DoctorDro |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dear all,
this is very easy to verify. On a clean installation of Julia type:
For more information on where the time is spent add a single line in the ipopt.opt file and save it:
Close and restart Julia for the changes to be applied and then try to solve the same problem again
The text was updated successfully, but these errors were encountered: