Rainer: There are some significant problems with this proposal. The premise that the profiling interface is only used early in the development is not correct. The PMPI interface is useful at almost every stage of the application's life time. One of the things that makes it successful is that it is always available and does not require recompilation. Making it optional would destroy that. I can tell you that one of the biggest problems for OpenMP has been the lack of a profiling interface. We recently had one sanctioned by the OpenMP ARB but that took a lot of effort since it is very hard to add it in after the fact. Your proposal would not be as drastic as eliminating the interface but the effect would be almost as catastrophic. Perhaps just as importantly to the general need of the interface, the idea that inlining of MPI will provide substantial benefits is inaccurate. MPI is a library interface. Many implementations are distributed only in binary form; unless you are proposing link time inlining (possible but not without its pitfalls), they will not gain any benefit from this. Even if we consider only open source MPI implementations, the VAST majority of users do NOT want to compile the MPI library. The possible performance gain is far too small for them to take on this task. A properly designed subsetting approach will NOT try to partition the profiling interface into its own subset. Instead, the interface must be partitioned into different subsets, with each PMPI function in the same subset as the corresponding MPI function. Bronis On Wed, 5 Mar 2008, Rainer Keller wrote:

Dear Alexander, dear all, at the previous Chicago meeting, some of us (Rich Graham, Jeff Squyres, Hubert Ritzdorf) have been discussing about the MPI-Standard's requirement to provide PMPI-functions for each MPI-Call into the library (except MPI_Wtime, MPI_Wtick).

This is in my eyes a limitation: there could be some gains for the common case of large-scale applications: - Not using PMPI-based tools (dynamically loaded in) - Not using MPI_PROC_NULL - Not using MPI_STATUS_IGNORE

So, if this proposal would fit Your definition of MPI3-Subsets, I would like to discuss the removal of the PMPI-function requirement, allowing inlining of MPI-functions and, based on that, pre-processor hints, e.g. MPI_HINT_NO_THREADS or MPI_HINT_NO_ANY_SOURCE, so the compiler might be able to eliminate several if-statements in the fast-path, allowing inlining, allowing dead code elimination. (of course, there is a whole lot of further issues involved, here -- please see the last section in the document).

I have included some timings with NetPipe on Open MPI using these hints (further information section 4 -- Ompi Patch availble upon request, as its work in progress). Please take the timings with a grain of salt. I would like to get better figures on a more well-defined cluster environment.

Any comments would be welcome.

With best regards, Rainer -- ---------------------------------------------------------------- Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller HLRS Tel: ++49 (0)711-685 6 5858 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832 70550 Stuttgart email: keller_at_[hidden] Germany AIM/Skype:rusraink