[MPI3 Fortran] Teleconference Wednesday, Sept. 17: Summary

[Supalov, Alexander]

PS. I would not say that there's resistance to the long counts. There's
just a number of ways how they can be introduced, and some interesting
implications in the file I/O and other areas that may not meet the eye
right away.

The matter of ILP64 support (i.e., ints as big as longs and pointers)
may be rather pertinent. Some guys have old Cray style apps that they
want to port. The MPI interface should behave nicely here, I'd say, if
only out of respect.

Another interesting aspect is the autodouble options, as some call it. I
believe this makes all reals be real*8. Again, some people use this,
mostly for the same reason, and Fortran MPI interface should probably do
something about this now, when we have the chance to do things "right",
for a change. :)

-----Original Message-----
From: Supalov, Alexander 
Sent: Wednesday, September 17, 2008 6:17 PM
To: 'MPI-3 Fortran working group'
Subject: RE: [MPI3 Fortran] Teleconference Wednesday, Sept. 17: Summary

Hi,

Thanks. I mentioned MPI_STATUS as a candidate for optional argument
status at the telecon as well. However, beyond that, one should probably
be rather conservative: it might be possible to imagine realistic
situations, in which an accidental erroneous call (with some omitted
arguments) might be treated as a valid one for a shorter set of
arguments. This may lead to very tough errors.

Best regards.

Alexander 

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org
[mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Jeff
Squyres
Sent: Wednesday, September 17, 2008 6:08 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Teleconference Wednesday, Sept. 17: Summary

On Sep 17, 2008, at 11:17 AM, Craig Rasmussen wrote:

>> 2. What KIND parameter to use for integer arguments.
>
> This topic took up most of the discussion.
>
> There are two sides to this:
> 1. From a users perspective it would be very convenient to use  
> default integers, especially for constants.
> 2. However from an implementation perspective, this becomes tricky  
> because it would require many more interfaces to be defined to  
> handle all of the different potential kind values.
>
> I think the resolution of this needs wider participation.  I was  
> persuaded that we should explicitly specify a kind value, C_INT, in  
> most cases.  This will work in most cases for default integer actual  
> arguments unless the user specifies compiler options to change the  
> default size.  When the user does this he/she should expect some  
> things to break and take the steps to correct the problem.
>
> Some arguments, for example, the count argument in MPI_Send should  
> require a kind large enough to store a pointer.

I'm not sure what this comment means ^^.

There is some debate in the MPI Forum to allow counts larger than a C  
int in MPI-3.0, but that discussion is very preliminary (there's some  
resistance to it because you can get arbitrarily large counts by  
composing MPI datatypes).

>> 5. Optional arguments?
>
> Yes, the error status parameter should be optional.  If other  
> parameters were made optional (e.g. MPI_COMM) the user may be  
> required to supply the argument name in the call, depending on what  
> arguments were left out.
>
> The decision was that ONLY the error status be optional.  However,  
> is it a bad think to allow the user to drop some arguments and  
> specify others by name?


It might be good to take a cue from the C++ bindings here.  We made a  
small number of arguments be optional -- such as those that have  
"IGNORE"-like constants (MPI_STATUS_IGNORE, MPI_ARGV_IGNORE, etc.).   
In fact, those arguments became somewhat of a PITA for the C++  
bindings -- it might very well be better to have multiple bindings for  
functions that allow IGNORE (or IN_PLACE) constants.  Perhaps  
something like this:

MPI_RECV(buf, count, type, src, tag, comm, status)
MPI_RECV(buf, count, type, src, tag, comm)
  --> ie., leave off the status argument altogether instead of passing  
MPI_STATUS_IGNORE

MPI_GATHER(sendbuf, sendcount, sendtype, recvbuf, recvcount, recvtype,  
root, comm)
MPI_GATHER(sendcount, sendtype, recvbuf, recvcount, recvtype, root,  
comm)
  --> i.e., leave off the sendbuf argument instead of passing  
MPI_IN_PLACE

Both of these examples should be pretty easy to match via overloading  
the functions.  The first one could probably be an optional argument  
since "status" is the last argument.  But I don't think the spec  
should mandate which way it is implemented -- I think the spec should  
only indicate which bindings should be available to user applications.

There's a few other obvious MPI API functions like this.

-- 
Jeff Squyres
Cisco Systems

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.