-
Notifications
You must be signed in to change notification settings - Fork 128
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
Added 3 64-bit MPI_Gatherv implementations #2405
Closed
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
helper::Comm
abstraction's methods use templating so that callers don't need to passsendtype
orrecvtype
explicitly. If we addGatherv64
that should be done here too instead of usingvoid*
.However, we shouldn't need to add
Gatherv64
. Thesendcount
argument in plainGatherv
is already asize_t
. Its existing implementation casts that toint
, which is the cause of the existing limitation. Instead of addingGatherv64
, you just need to update the implementation ofCommImplMPI::Gatherv
to use the block approach. IIRC some of the other methods inCommImplMPI
already do that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason to have some extra Gatherv64 implementations rather than modifying the existing Gatherv is because for use cases which does not exceed 2GB, the original Gatherv is still more optimal. If we completely remove the original Gatherv, it means that these use cases will get worse performance.
Due to the fundamental mechanism of MPI, it's also undesirable to determine 32-bit or 64-bit at runtime. Because in some cases, it's possible that only a few of the senders actually exceed the 32-bit limitation. If we determine this locally, it will cause unmatched MPI operations across all ranks. If we determine this globally, it will introduce extra MPI global operations than what is necessary to perform the Gatherv itself.
So currently the most optimal way I can think of is to keep these 32-bit and 64-bit implementations, and let specific engines to determine which to use based on it's scopes, use cases, assumptions, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The missing templated functions were added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The existing
Gatherv
takes asize_t
count and should not fail when given a size larger than 32-bits. ThereforeGatherv
's implementation should be fixed to support 64-bit sizes somehow. If a non-MPI backend is added in the future it might not need any special help or chunking.To retain efficiency for callers that know their sizes fit in 32 bits we could offer a
Gatherv32
that takes auint32_t
as a size (or if MPI is actually limited by a signedint
then maybe evenGatherv31
taking aint32_t
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original MPI_Gatherv is for sure limited by a signed int, which is exactly the reason why I am doing the whole lot of this. Not only MPI_Gatherv, but also all MPI functions that take int as the size, are limited by a singed int. If you think in that way, then you will need to re-implement EVERY SINGLE MPI function in the Comm class to support 64-bit. Is that what you think we are supported to do? Even if the answer is yes, at least it's far beyond the scope of this PR...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I guess that's a good argument, mismatched calls obviously is obviously a bad outcome. Well, so the one thing I'd definitely still suggest is to make the version that uses
MPI_Gatherv
throw an error if any arguments are out of range. But it does look like it's not easily possible to have a single interface and decide at runtime.The iffy thing with this is that errors will only occur in rare circumstances, so will be difficult to test for. If one has
GatherV
andGatherV64
, then the question is, can you ever useGatherV
safely, ie. guarantee at compile time that the args will never be > 32bit?Not sure what the best solution is. This would be all much easier if they could have settled on a 64-bit solution within the MPI standard...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@germasch If an engine blindly uses Gatherv, then it's for sure unsafe. But the engine can determine this in several ways. It can do an MPI collective operation before calling Gatherv and then call Gatherv or Gatherv64 accordingly if it does not care about the overhead. If it does care, however, it can ask users to pass a static engine parameter, to specify whether > 32 bit case is ever supposed to happen. For most of the applications, this should be a statically known knowledge.
The reason why I am thinking it in such a uncommon way, is also because the actual applications that need 64 bit are very rare, and they probably only need Gatherv for aggregating metadata, but don't need other MPI functions being operated at 64 bit. If just for one or two this kind of apps, we re-implement the whole MPI software stack, it does not sound like a smart thing to do. If all other functions are actually 32-bit but with a 64-bit wrapper, why do we make Gatherv such an exception by have Gatherv32 and Gatherv? In the current status of the Comm class, having a Gatherv and a Gatherv64 is a very natural thing, unless all other 32-bit MPI functions with 64-bit wrappers are already addressed correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, eventually. That was my intention when introducing the
Comm
abstraction. IIRC some of the methods have the chunking already.My suggestion is to re-implement the existing
Gatherv
using your 64-bit implementation, and introduce a newGatherv31
method that has theint
-based limitation builtin to its interface. This change is inside our internal API and does not need to affect applications. Just update all our internal call sites (there are only a couple of them) to switch fromGatherv
toGatherv31
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bradking Sounds reasonable. Do you want me to do it in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest opening a new PR to rename the existing
Gatherv
toGatherv31
, change its signature, and update all its call sites in one step. That way we can be sure no call sites accidentally use the 64-bit variant. After that is merged, rebase this PR to restore theGatherv
with its original signature and use the chunking implementation.