mpich
mpich copied to clipboard
MPI-4: Missing MPI_Status_set_elements_c
This is technically not an omission MPICH. Looks like MPI standard forgot to add a new MPI_Status_set_elements_c
routine. However, it would make a lot of sense to add it provisionally, at minimum a as #define to the _x
routine in mpi.h.
@raffenet Comments?
I am not sure that MPI forum "forgot" or intentionally didn't introduce "MPI_Status_set_elements_c", and mpich as an implementation, is not going to introduce the new routine. The best we can do is to use MPIX_Status_set_elements_c
. But user can add that macro if so desired, so I think we are reluctant to add that.
I believe they forgot. Otherwise why would MPI-4.0 have the following two getter routines with exactly the same signature, but only one for the setter?
int MPI_Get_elements_c(const MPI_Status *status, MPI_Datatype datatype, MPI_Count *count)
int MPI_Get_elements_x(const MPI_Status *status, MPI_Datatype datatype, MPI_Count *count)
In any case, I understand your concerns and rationale. Let's wait for a errata, or more likely a fix in MPI 4.1.
I feel like rather the addition of MPI_Get_elements_c
was a mistake, but I'm not sure. In any case, I'll take it up with the forum to discuss.
I feel like rather the addition of
MPI_Get_elements_c
was a mistake
Well, that's certainly a valid way to see it. But for the sake of consistency on naming conventions, adding MPI_Status_set_elements_c
would also makes sense, doesn't it?
BTW, with the addition of MPI_Get_elements_c
as a variant, some of the discussion in the text referring to MPI_Get_elements_x
looks a bit outdated.
@dalcinl Shall we close this issue?
@dalcinl Shall we close this issue?
Yes, sure.
@hzhou @raffenet Should we reopen this issue? As I do not have access to the in-development MPI standard documents, I'm not really sure whether MPI_Status_set_elements_c
was added as an errata to 4.0 or an upcoming revision 4.1. Note that the MPI-forum issue do have a mpi-4.0
label.
@dalcinl we can fix that
@dalcinl we can fix that
Welcome to the club and congratulations. 😄
Guys, just a quick question. What the exact meaning of the "errata" label in the forum repo? Is this new routine part of MPI-4.0 or an upcoming minor revision MPI-4.1 ?
If something is labeled as “errata”, it was an error in a previous version of the standard and therefore it’s immediately applicable to the version where it occurred when it passes a vote. So in this case, MPI 4.0 now includes the changes to fix the missing function.
That being said, the PDF doesn’t change and the amendment is in a separate document where we include all of the errata.
I'll note that this is consistent with the centuries old practice with errata in printed books, for better or worse.
I'll note that this is consistent with the centuries old practice with errata in printed books, for better or worse.
We are talking about a 1K pages document that will never appear in printed form.... And
My real concern is with this practice of adding band-new functions to the standard in a retroactive way. Now the MPI_VERSION
and MPI_SUBVERSION
macros cannot be used to rely on whether MPI_Status_set_elements_c
is available or not. Moreover, a major MPI implementation (MPICH) was already released to the public with the version/subversion macros with values 4/0 but without the new MPI_Status_set_elements_c
routine.
Yeah, I understand the practical consequences, but @jedbrown will tell you not to use MPI version macros anyways, since many implementations state they support a version of the standard when their implementation contains numerous defects, including intentional features omissions.
In your case, just keep using MPI_Status_set_elements_x
, which is identical. You overload MPI_Status_set_elements
anyways, rather than exposing MPI_Status_set_elements_c
to users, right?
As an aside, I am currently trying to have ARMCI-MPI detect which minor version release of dependent libraries MPI libraries are using, in order to determine if RMA features are going to work, if that makes you feel any better 😜