You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Working group feedback on Trac #423 motivates a new ticket to make large-count equivalents of "all" the datatype constructors, etc.
Overview
Since we don't support counts larger than INT_MAX, at least in the C interface, it would be nice to make it easy for users to work around this. And, lest there be any doubt, users are hitting this issue in real applications, e.g. NWChem.
It was originally proposed to only add a large-count contiguous type, but that is unappealing on many counts, because it breaks an obvious symmetry and looks like a bandage.
I argue that most users would find this type of modification to their code relatively non-intrusive and a reasonable workaround for the large-count case.
Motivation
Unfortunately, using the existing MPI functions, construction a contiguous datatype for large counts is not very simple. Below is what I believe is the most efficient implementation of a general, contiguous large-count datatype. It requires six MPI function calls to do something that is trivial. I'm not arguing that function call overhead is a performance issue compared to shipping more than INT_MAX elements, but rather it is a productivity overhead to ask users to duplicate the following effort to be fully general and avoid overflow hazards.
See type_contiguous_x.c for the implementation that avoids the user of MPI_Type_create_struct whenever an appropriate factorization can be found.
I propose to add the equivalent of the aforementioned function to the standard so that it can be implemented properly and save users the pain of having to use the following type of approach in their codes. While it can certainly be argued that users can just figure out how to solve the problem on their own, I don't believe it is an appropriate burden to put this burden on the user.
Implementation status
MPICH
An MPICH implementation is complete except for testing. It was essentially trivial except for adding all of the interface magic.
Here is my prototype implementation in MPICH. The essential commits to inspect are
The combiners to be added follow the naming structure MPI_COMBINER_CONTIGUOUS_X for MPI_COMBINER_CONTIGUOUS and so forth.
The text was updated successfully, but these errors were encountered:
jeffhammond
changed the title
add large-count datatype constructors, etc. (was Trac ticket 468)
add large-count datatype constructors, etc. (Trac #468)
Dec 3, 2015
History
Working group feedback on Trac #423 motivates a new ticket to make large-count equivalents of "all" the datatype constructors, etc.
Overview
Since we don't support counts larger than
INT_MAX
, at least in the C interface, it would be nice to make it easy for users to work around this. And, lest there be any doubt, users are hitting this issue in real applications, e.g. NWChem.It was originally proposed to only add a large-count contiguous type, but that is unappealing on many counts, because it breaks an obvious symmetry and looks like a bandage.
Usage
For example:
I argue that most users would find this type of modification to their code relatively non-intrusive and a reasonable workaround for the large-count case.
Motivation
Unfortunately, using the existing MPI functions, construction a contiguous datatype for large counts is not very simple. Below is what I believe is the most efficient implementation of a general, contiguous large-count datatype. It requires six MPI function calls to do something that is trivial. I'm not arguing that function call overhead is a performance issue compared to shipping more than
INT_MAX
elements, but rather it is a productivity overhead to ask users to duplicate the following effort to be fully general and avoid overflow hazards.See type_contiguous_x.c for the implementation that avoids the user of
MPI_Type_create_struct
whenever an appropriate factorization can be found.I propose to add the equivalent of the aforementioned function to the standard so that it can be implemented properly and save users the pain of having to use the following type of approach in their codes. While it can certainly be argued that users can just figure out how to solve the problem on their own, I don't believe it is an appropriate burden to put this burden on the user.
Implementation status
MPICH
An MPICH implementation is complete except for testing. It was essentially trivial except for adding all of the interface magic.
Here is my prototype implementation in MPICH. The essential commits to inspect are
Additional references
BigMPI is my project to support large-count interfaces for all of the MPI communication functions for which they make sense.
Query Functions
In order to query the datatype created by e.g.
MPI_TYPE_CONTIGUOUS_X
, we need the following functions.The combiners to be added follow the naming structure
MPI_COMBINER_CONTIGUOUS_X
forMPI_COMBINER_CONTIGUOUS
and so forth.The text was updated successfully, but these errors were encountered: