Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unnecessary allocations when using PanuaPardiso #174

Open
mipals opened this issue Jun 19, 2024 · 0 comments
Open

Unnecessary allocations when using PanuaPardiso #174

mipals opened this issue Jun 19, 2024 · 0 comments

Comments

@mipals
Copy link

mipals commented Jun 19, 2024

PanuaPardiso expect that the colptr and rowval are Int32. However, on many systems the KKT matrix will be saved as a SparseMatrixCSC{T, Int64} matrix instead of a SparseMatrixCSC{T, Int32} matrix. This mean that Pardiso.jl has to convert colptr and rowval to Int32 every time any functionality is called, leading to unnecessary computation and memory allocations. I think that this is not be an issue for MKLPardiso as here pardiso_64 should be called when LinearAlgebra.BlasInt = Int64, but have not been able to test this.

A simple fix could be to save Int32 copies of colptr and rowval in the ldlsolver and then call Panua directly using ccall. The downside is that the code would most likely require a split between Panua and MKL.

To highlight the issue I've attached timers for the current implementation and the possible fix below.

Current

 solve!                 1    3.55s   82.2%   3.55s   1.96GiB   94.7%  1.96GiB
   IP iteration         1    3.43s   79.4%   3.43s   1.90GiB   92.1%  1.90GiB
     kkt update        26    2.16s   50.1%  83.2ms    925MiB   43.7%  35.6MiB
     kkt solve         52    1.14s   26.3%  21.9ms    921MiB   43.5%  17.7MiB
     scale cones       26   32.5ms    0.8%  1.25ms    102MiB    4.8%  3.94MiB

Saving colptr and rowval and calling Panua directly

 solve!                 1    3.51s   83.3%   3.51s    329MiB   73.9%   329MiB
   IP iteration         1    3.40s   80.6%   3.40s    325MiB   72.9%   325MiB
     kkt update        26    2.14s   50.8%  82.5ms   75.7MiB   17.0%  2.91MiB
     kkt solve         52    1.10s   26.0%  21.1ms    123MiB   27.6%  2.37MiB
     scale cones       26   48.0ms    1.1%  1.85ms    102MiB   23.0%  3.94MiB

The time difference is probably negligible for this small problem, but the allocation reduction is quite significant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant