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

Degradation of Performance when using 1xP grids #100

Open
swathy3 opened this issue Sep 26, 2024 · 3 comments
Open

Degradation of Performance when using 1xP grids #100

swathy3 opened this issue Sep 26, 2024 · 3 comments

Comments

@swathy3
Copy link

swathy3 commented Sep 26, 2024

The cost of communication seems more prevalent when using Symmetric Eigen solvers (PXSYEVD) with 1xp grids. How should the grid be distributed when NPROCS is prime? How can I force the system to keep some nodes idle in this case? Which of the layers would need modifications? ScaLAPACK, PBLAS or BLACS? Any insights in this area would be helpful.

@zerothi
Copy link
Contributor

zerothi commented Sep 26, 2024

You have to create a communicator with a size that can be grided. Then redistribute the matrices...

@swathy3
Copy link
Author

swathy3 commented Sep 30, 2024

What if I am forced to create a 1xP grid for maximum utility of the system's hardware? The grid parameters are set by the application and I cannot tweak them.
I'm trying to launch the application under two scenarios

  1. -np 189, with grid params 9x21(PxQ)
  2. -np 191 (max possible in the target system), with grid params 1x191(PxQ)
    I see considerable degradation in performance with the second case. However, I would expect improvement with increase in number of processes? Is there any layer of the ScaLAPACK I can exploit to resolve this case when I encounter a prime?

@zerothi
Copy link
Contributor

zerothi commented Sep 30, 2024

  1. Well, you could choose block sizes that are so large that the last proc does not hold anything, but that also seems sub-optimal. I would suggest you reduce your comm-size. If 189 performs much better than 191, then that is obviously using your resources much better.

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

2 participants