Skip to content

Setting default algorithm to discover the communication graph #213

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

JordiManyer
Copy link
Contributor

@JordiManyer JordiManyer commented Aug 13, 2025

The current default algorithm to discover non-symmetric communication graphs is based on a gather-scatter algorithm. This works great for small communicators, but becomes prohibitive for large problems. The other available algorithm works great, and greatly reduces the amount of memory needed on the master processor.

Although there is technically a way to choose which algorithm you are using, it is extremely tedious and you have to go very low-level to actually be able to change it.
The option I've been using is to overwrite the default_find_rcv_ids function on my packages, but this breaks precompilation and is nothing more than a hack.

Due to this, I propose adding a compile-time preference through the Julia-standard Preferences.jl package. This changes the default behaviour of PartitionedArrays and sets the other algorithm as default.

The changes have zero impact on performance, since everything is done at compile time by using @static if-else statements.

Let me know what you think @fverdugo

@fverdugo
Copy link
Collaborator

Hi @JordiManyer,

Is is going to generate a Preferences.Toml file if a user does nothing?

@JordiManyer
Copy link
Contributor Author

Hi @fverdugo , not at all. The local file only gets created if the defaults get changed, like for MPI.jl. Otherwise the package bahaviour is unchanged and the user does not notice.

@fverdugo
Copy link
Collaborator

Good!

Can you then fix the documentation? It is failing to build.

@JordiManyer
Copy link
Contributor Author

Yes, Ill do some final changes if you are happy with the overall concept. Some questions:

  • Any comments/preferences on the function names?

  • Do you want to keep this like it is in a separate file? Where do I put the documentation?

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 this pull request may close these issues.

2 participants