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

Evaluating solver performance in BENCHMARK with different reordering algorithms #1374

Closed
stanisic opened this issue Jul 25, 2023 · 2 comments · Fixed by #1408
Closed

Evaluating solver performance in BENCHMARK with different reordering algorithms #1374

stanisic opened this issue Jul 25, 2023 · 2 comments · Fixed by #1408

Comments

@stanisic
Copy link

I would like to benchmark the impact of different reordering algorithms (most importantly RCM) already implemented in Ginkgo on the total time to solve some matrices. Ideally, this would be a BENCHMARK option similar to PRECONDS, but I understand that implementing and documenting this properly might take some time. Until then, I would highly appreciate any quick, dirty and temporary patch/suggestion :)

BTW I already tried the code implemented in PR #1354, and it indeed helps evaluating performance of reordering algorithms themselves. However, I am not confident that I know what the correct way would be to integrate something similar into solver benchmark.

@upsj
Copy link
Member

upsj commented Sep 22, 2023

I am not sure how much we should be extending the run_all_benchmarks.sh script, I don't think we're using it anywhere outside CI benchmarking jobs.

@stanisic
Copy link
Author

stanisic commented Oct 4, 2023

run_all_benchmarks.sh script is very convenient for benchmarking Ginkgo's performance in order to find hotspots, compare it to the other solvers... Therefore, in our team we used this script extensively. I do not know if there are many other external users like us.

That being said, I followed the discussion in #1408 and I understand now why adding this as a cross-product to already existing precond-solver combination is probably not a good solution. I guess solutions proposed in #1408 should be OK, especially if combined with description/examples on BENCHMARKING documentation page about how to benchmark different reordering algorithms.

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

Successfully merging a pull request may close this issue.

2 participants