Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] [EXTERNAL] Re: MPI_Mprobe
From: Barrett, Brian W (bwbarre_at_[hidden])
Date: 2012-08-14 11:10:29


On 8/14/12 8:30 AM, "Jeff Squyres" <jsquyres_at_[hidden]> wrote:

>On Aug 14, 2012, at 10:04 AM, Barrett, Brian W wrote:
>
>> That's incorrect. Fortran statuses should never be passed to C
>> interfaces. If you look at testany_f.c, for example, a temporary status
>> is created and then passed to the C binding
>
>I think the issue is that there is a mix of both styles. Look at
>recv_f.c, for example -- in some cases, we pass the Fortran integer array
>(if the sizes are equal), and in other cases, we use a temp C MPI_Status.

Sounds like a Fortran problem to me ;).

>> (although, in this case, it
>> would probably be more efficient to pass it directly to
>> ompi_request_testany(), but that's not important here).
>
>Probably so. No one has undertaken an effort to have the mpif.h
>interfaces directly call the back-end OMPI functions (vs. the MPI
>functions). It might be worthwhile if someone has an intern / student
>and wants to come up to speed on OMPI internals -- e.g., they could at
>least remove some of the calls to MPI functions from performance-critical
>mpif.h functions (e.g., MPI_Send, MPI_Recv, ...etc.).
>
>> The part that is
>> important is that outside of the Fortran interfaces themselves, requests
>> are always C requests.
>
>George and Eugene came to similar conclusions on
>https://svn.open-mpi.org/trac/ompi/ticket/3218.
>
>However, there is a downside (as Eugene pointed out): with the C
>bindings, we usually (always?) end up copying the status once (from the
>back-end request to the user-specified status). If we go the
>use-a-C-MPI_Status route in for the mpif.h bindings, then we'll end up
>copying the status twice (back-end request -> temp C MPI_Status ->
>fortran INTEGER array).

I agree, although I'd prefer that over a bunch of macros in the MCA code,
particularly OB1.

Brian

-- 
  Brian W. Barrett
  Dept. 1423: Scalable System Software
  Sandia National Laboratories