[Mpi3-bwcompat] Stealing the working group

[Solt, David George]

>> Thanks for the suggestions.  I'm reworking the last proposals a bit.  My goal is to come up with something that allows for most interfaces (all but f77) to have a way to do large counts, leave f77 alone, and still have some consistency across languages and across what we already do.  
>> 
>> 1) Function overloading as available in Fortran90 and newer right?
>
>I'd vote for the F2003 MPI bindings and later.  I don't really want to touch either the F77 or F90 bindings.

If we are going to introduce a new TYPE, then I like this better because of my complaint about handling MPI_Count different from MPI_Request, etc.

>> 2) One concern I have with going to MPI_Count is that I think that MPI_Send(buf, 10, ....) should always be legal.   If we introduce a type that is up >to the implementation, then that may not be legal any longer?  Do we specify in the standard that MPI_Count MUST be defined by the implementation to be >something that can be cast to/from an integer constant?
>
>Can you give an example where it won't be legal?

Ignore me.  I confused myself.  Since we don't have any other types right now that allow the user to set it directly without a set function, I was thinking that MPI_Count is an opaque object like our other types (except status).  But obviously we want to be able to do:

MPI_Count x;
x = 10;

And not

MPI_Count x;
MPI_Count_create(&x);
MPI_Set_count(&x, 10);
...
MPI_Count_free(&x);

Ha, ha.  This is a ridiculous, of course, but I lost track of myself when I was thinking about passing constants to functions that take an MPI_Count.

>> 3) Another concern with introducing MPI_Count TYPE in Fortran90/newer is that it is inconsistent with the way other types are handled (MPI_Comm, MPI_Request, MPI_Info, etc.)   It seems a bit strange to me that we are going to pick out this one thing and make it a TYPE in all newer Fortrans even though everything else is declared as an INTEGER.
>
>In the F2003 bindings, we have opaque types for all the MPI handles -- they're no longer integers.
>
>:-)

Ok, more reason to do MPI_Count and only change C, F2003 (and C++ of course!).  One reason I was leaning towards not using MPI_Count and simply changing the type to 'long int' and 'integer*8/KIND=8' is to avoid any concerns that people may have that you won't get warnings when you pass integers where MPI_Count is expected.  The prototype I did showed that it was not an issue, but there may still be psychological barriers that we are depending too much on compiler behaviors.   Another reason is that we now have to explain that MPI_Count is not an opaque object, so what is the benefit of making it a type?  In fact, I wonder if we really want to be very clear how big the count is.  We don't want the user to have some code that gets compiler warnings with one MPI and not with another one because one MPI defines it as an int and another defines it as a 'long int'.   Then my code:

long int x = 1;
MPI_Count y;
y=x; 

compiles with no warnings with one MPI and gives me warnings with another MPI because MPI_Count now isn't big enough.   

>That being said, there were some technical issues raised at the Portland meeting -- I can't remember many of them now, but one sticks out: what about functions that take a count as an OUT argument?  Those can't just seamlessly be recompiled (unless MPI_Count === int).

Oh yeah.  I need to address that in the slides.   Let me see exactly how many of these there are.  If it is not too bad, maybe we can get by with some new interfaces for getting back long counts and otherwise the current extraction routines will need to return an error on truncation.  I don't think that most of these are used very commonly and an application that wants to pass large counts already has to change its code to avoid its own application level count overflows, so requiring a code change here should be acceptible.  If you can think of any of the other issues let me know.


-- 
Jeff Squyres
jsquyres_at_[hidden]
_______________________________________________
Mpi3-bwcompat mailing list
Mpi3-bwcompat_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat