-> From: "Eric Salo" <salo@mrjones.engr.sgi.com>
-> Date: Thu, 13 Jun 1996 17:36:28 -0700
-> To: mpi-core@mcs.anl.gov
-> Subject: Re: YASM
->
-> In regard to my specific suggestion of adding a new send mode, I see here a
-> potential for a truly significant performance boost on any system that supports
-> multiple processes with shared memory segments, including uniprocessors. For
-> systems which would not see a boost the cost of implementation would be
-> basically zero, ....
The cost is never basically zero. For the implementor there may be relatively
little costs to these irrelevant functions to prevent linker errors. However
we cannot ignore the cost of documentation and evaluation. This are significant
The standard as resulting from the MPI-Forum is poor documentation, rarely
even clearing indicate possible return values of functions.
And I have not met an Evaluator yet who believes me when I say a function is
a no-op. Take a function like MPI_Window_in that was first advertise as
basically a no-op on many systems. Some evaluators would interpret (page 94,
line 21) "but the local copy of the window should not be updated locally" to
imply that a high quality implementation should prevent a local update.
Also (page 91, line 46,47) "Before using loads and stores on the target process to
access data updated by a prior RMA operation, the target process 'must' first
issue a call to MPI_WINDOW_IN", would surely be interpreted by most evaluators
as some kind of error needs to be generated if this is not the case.
And what exactly are the possible return values of MPI_WINDOW_IN???
Portable evaluation suite writers might spend a great deal of time trying
to evaluate these meaningfully.
joel
--- End Of Your Message