Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: [slightly] Optimize Fortran MPI_SEND / MPI_RECV
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-02-04 17:18:12

I forgot to mention -- here's a hacked up proof-of-concept that shows
exactly what I'm talking about:

On Feb 4, 2009, at 5:03 PM, Jeff Squyres wrote:

> WHAT: Have Fortran MPI_SEND/MPI_RECV directly call the corresponding
> PML functions instead of the C MPI_Send/MPI_Recv
> WHY: Slightly optimize the blocking send/receive in Fortran (i.e.,
> remove a function call)
> WHERE: ompi/mpi/f77/*.c -- possibly add an --enable switch to
> configure to enable/disable this behavior
> WHEN: For OMPI v1.4
> TIMEOUT: Tuesday teleconf, 17 Feb 2009
> -----
> Taking some inspiration from NEC MPI, it might be useful to remove
> an extra function call from some common Fortran MPI functions (I'm
> specifically proposing MPI_SEND/MPI_RECV, but others could be done
> as well). Specifically, instead of having the Fortran MPI_SEND/
> MPI_RECV call the C versions of MPI_Send/MPI_Recv, they could just
> do [almost] exactly the same thing as the C versions: error checking
> on the MPI parameters and calling the PML back-end functions.
> The net performance win for this is likely very small. However,
> this idea has been on my to-do list for forever, so I thought I'd
> ask if people cared/objected.
> Benefit
> - Remove a function call from the critical performance path;
> possibly save a little latency
> Drawback
> - Duplicate some code (but this code rarely/never changes)
> - May violate MPI profiling libraries that assume that the Fortran
> MPI API functions call the C MPI API functions
> Granted, on the NEC platform, function calls are *VERY* expensive --
> so having their Fortran MPI API functions directly call their back-
> end functions makes much more sense than calling the C API
> functions. On the OS's and platforms that OMPI supports, we'll
> likely see a much smaller benefit (indeed, its effects may only be
> visible over shared memory -- if at all). But it may be worthwhile
> just in the "it's the right thing to do" category.
> Thoughts?
> --
> Jeff Squyres
> Cisco Systems
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
Cisco Systems