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: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-08-14 11:49:09

Noted in

On Aug 14, 2012, at 11:10 AM, Barrett, Brian W wrote:

> 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
>> 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
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
For corporate legal information go to: