Forgot about our friends MPI_Aint, MPI_Fint and MPI_Offset. I guess at MPI-1 time, MPI_Aint was much like we are proposing MPI_Count to be... up to the implementation in C and always an integer in fortran77. MPI-2 fixed that "mistake?", but we want MPI_Count to be like MPI_Aint was for MPI_Type_hvector and friends during the MPI-1 timeframe.
I don't think we want to go there. YMMV if you mix types -- I think that's a C issue, not an MPI issue.
I agree, we already could have that issue with MPI_Aint, so we are not introducing anything new. I'll ask Rich about notes and I'll send another copy of the MPI_Count slides later. Thanks, Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, January 07, 2010 3:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Stealing the working group On Jan 7, 2010, at 4:12 PM, Solt, David George wrote:
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?
Nah -- we already have MPI_Aint, MPI_Fint, and MPI_Offset. Those are all declared to be integer types that are not opaque.
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.
I don't think we want to go there. YMMV if you mix types -- I think that's a C issue, not an MPI issue.
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.
Someone took notes at the Portland meeting -- it would be worth digging them up. I'm quite sure that we're not remembering all the points that were brought up (there was a lot of useless FUD, but there were some good technical points, too). -- Jeff Squyres jsquyres_at_[hidden] _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat