I forgot to mention -- here's a hacked up proof-of-concept that shows
exactly what I'm talking about:
http://www.open-mpi.org/hg/hgwebdir.cgi/jsquyres/fortran/rev/9880d70927cc
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
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems