There are cases like MPI_PACK where an extra arg makes sense
and saves us from adding many functions to MPI-1 that
even if "organized well" wouldn't add to the clarity.
There are other cases like MPI_SEND where I would not want
to see an extra arg that specified (blocking, nonblocking, sycn, ready,...)
because I think it is clearer to the user to have separate functions.
At the upcoming meeting we need to decide in what category
we want MPI_SPAWN to be in.
>I have never heard a user say that they
>wished MPI did *not* have a particular function.
Why should they? They do not have to implement, test, or maintain MPI.
The vendors get stuck with this burden. Let them scream.
What I do hear regularly is a perception that MPI is bloated.
Perception can scare people off from even trying MPI
and this isn't good. We need to carefully determine if
enumerating the different versions of a function really
buys us anything.
Performance isn't much of an issue with inherently slow MPI_SPAWN,
but there are other considerations that have been aired in the newsgoup.
In the case of MPI_SPAWN, I still favor the new proposal.
Not because it has 5 functions vs. 24, but because I
think the users will find this dynamic process API clearer,
and less bloated.
Al Geist