-
Notifications
You must be signed in to change notification settings - Fork 274
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
ABI: How to handle optional datatypes? #6877
Comments
Both |
Perhaps If we allow Making everything but |
We can think of this another way. For example, Therefore, it might be reasonable to defer errors until reductions are used, because that's the only place where there is a real problem. I recognize this is problematic for users to detect support for such types, hence it may be necessary to add a utility function to query for optional type support. I'll note that today we already have a problem in this area because all the MPI implementations are doing arithmetic in C, which means that if a Fortran compiler ever defines arithmetic in a different manner than C, MPI implementations will product incorrect results.
|
What about
I definitely agree we still need something to flag optional types. However, rather than adding a new API, my proposal of "reusing" |
You're right, although the propsoed Because the size of the default integer and real types isn't specified in the ABI, those can't be used at all when they are unsupported. |
No idea what are you talking about 😥.
Then back to my original point, even if We can think of this another way and defer errors as you said, in the end we would still need a runtime mechanism to flag optional datatypes. |
I like this. Now I recall this was my thinking several years ago :) . We can always define a type size and always define the datatype. The type size may be inaccurate if the supported language/compiler, e.g. Fortran, do not support it, but that shouldn't cause user issues since users shouldn't be using it from the unsupported languages anyway. The reduction should fall for such datatypes when the implementation can't do it -- this is the current behavior anyway. This removes the question of datatype availability altogether. If it compiles, it is available. Whether reduction is supported is a separate question. |
In the current MPICH ABI, optional unsupported datatypes are set to
MPI_DATATYPE_NULL
. This allows for an easy check at runtime to determine whether any optional datatype is actually available.Within the new in-development MPI ABI walls, optional datatypes have an integral value different from the
MPI_DATATYPE_NULL
datatype handle. However, in the current MPICH implementation for the new MPI ABI, unsupported datatypes (e.g.MPI_INTEGER16
,MPI_REAL2
,MPI_COMPLEX4
) get eventually translated back toMPI_DATATYPE_NULL
, and using them in any current MPI API will trigger an error. Therefore, there is no way to check whether an optional datatype is supported or not.Relying on error handling is cumbersome in general, as it would require querying the current error handler, overriding with
MPI_ERROR_RETURNS
, then call a datatype API likeMPI_Type_get_size
, check for the return error code, restore the original error handler and free the reference.How are we going to handle this issue? At first, I thought about adding some sort of custom workaround for MPICH. But this issue would be exactly the same with any MPI implementation, so IMHO it is worth to explore a more general solution.
For example we could mandate
MPI_Type_size()
to return0
or even betterMPI_UNDEFINED
, although it feels a bit awkward to use that routine for such purpose. A possibly nicer and general solution I came up with is adding aMPI_COMBINER_UNSUPPORTED
value to be returned fromMPI_Type_get_envelope
to flag unsupported datatypes. Or perhaps even better, returncombiner=MPI_UNDEFINED
, this way we do not need to introduce a new constant.cc @jeffhammond
The text was updated successfully, but these errors were encountered: