[Mpi-22] [MPI Forum] #117: Define a new MPI_Count Datatype

[Solt, David George]

I want to make everyone on the 2.2 list aware of this update to ticket #117:

Thanks,
Dave Solt

-----Original Message-----
From: MPI Forum [mailto:mpi-22_at_[hidden]] 
Sent: Monday, May 11, 2009 12:52 AM
Subject: Re: [MPI Forum] #117: Define a new MPI_Count Datatype

#117: Define a new MPI_Count Datatype
----------------------------+-------------------------------------------
----------------------------+----
Reporter:  kannan           |            Owner:  davesolt             
    Type:  New routine(s)   |           Status:  new                  
Priority:  Had 1st reading  |        Milestone:  2009/06/08 California
 Version:  MPI 2.2          |       Resolution:                       
Keywords:                   |   Implementation:  Waiting              
----------------------------+-------------------------------------------
----------------------------+----
Changes (by davesolt):

  * owner:  kannan => davesolt

Comment:

 I have reassigned this to me as my colleague, Kannan, has moved on to a  different role within HP.  I have been working to come up to speed on this  ticket and provide a reference implementation with Open MPI, which I have  made available at:

 http://bitbucket.org/jsquyres/mpi-count/

 Thanks to Jeff S. for his help on setting this up.  The implementation is  for C and Fortran 90.  It does not include C++, although I have manually  verified that C++ does work in the same way.  The goal of this prototype  is to demonstrate that applications can be compiled with a header file  that uses the previous interface definitions and then dynamically linked  against an MPI that uses the new interfaces.  However, this implementation  reflexively demonstrates the feasibility because only the header files  where changed.  Therefore, an application compiled with this  implementation will be compiled against a different header file than the
 associated library uses for its own definitions.   For example, the mpi.h
 header file defines MPI_Send with an MPI_Count argument.  Internally, the  library defines MPI_Send using an int argument.  Applications compiled  against this header file will run with this implementation, proving that  the header file difference does not actually change the signatures in a
 significant way.   In addition, an application compiled with the "old"
 header file will run against this implementation.  There are example files  in the 117 directory to test with.

 In the course of this work I did come to wrestle with some of the same  issues brought up on this list:

 1) MPI_Type_size, etc.

 >>    What about MPI_Type_size now that all the datatype constructors take
 MPI_Count?
 >
 >My rationale -- I'd left out converting size arguments/return values on  other APIs >since I targetted MPI_Count to represent only the count type,  and not get into the >promotion of sizes. I agree that logically  MPI_Type_size has to be promoted, but >that would mean that we would now  have to go thru every API that takes in/ returns >sizes and look for  candidates.

 I also found it difficult to draw a line at what other arguments need to  be converted to account for the fact that the proposal allows for large  datatypes.  In retrospect, I wish that the proposal had not attempted to  allow for large datatypes and had limited itself to communicating calls.
 Some other calls such as MPI_Unpack and MPI_Type_size are clearly  incompatible with the proposed changes.

 2) MPI_Type_get_envelope, MPI_Type_get_contents

 I believe that since these return values that were set by creation
 routines, some of these arguments need to be MPI_Count sized as well.   In
 the prototype implemenation, I did change these arguments, but have not  yet made any changes to this proposal

 3) MPI_Type_create_struct

 The proposal is to change argument #1, but I believe this is incorrect.
 Argument #1 is the number of items in the struct, which is likely to not
 be > 2GB.   However, the 2nd argument is the size of individual elements,
 which I believe is the argument we intend to change.

 4) MPI_Status_set_elements

 This is not included in the proposal, but I believe that argument #3  should clearly be MPI_Count sized since the proposal is that the count  field of status can be > 2GB.

 5) MPI_Type_create_darray

 I believe this was an oversight and this datatype creation routine should  have argument #3 changed to MPI_Count.  I would appreciate some other  input on this one as I do not have a lot of experience with this  particular function.


--
Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117#comment:38>
MPI Forum <https://svn.mpi-forum.org/>
MPI Forum