On Sep 27, 2004, at 5:05 AM, hedman_at_[hidden] wrote:
>>>>>> On Fri, 24 Sep 2004 14:22:34 -0400, Jeff Squyres
>>>>>> <jsquyres_at_[hidden]> said:
> jsquyres> That's all fine and good, but it's just not
> jsquyres> part of MPI. :-) This would have to be
>
> I know that it is not MPI, but rather something that I wish
> would be there:)
:-)
> One problem with the C++ interface of MPI is that it was
> done before STL and as it stands today I can not see what it
> really adds over the C API. Sure namespaces and exceptions
> are used and it is object based, but why all the virtual
> functions in the interface? I would assume that a library
> builder of today would aggregate MPI objects rather that
> inheriting the interface. Furthermore, using MPI with data
> stored in a e.g. std::vector is awkward, and there are also
> sometimes odd data-types in the interface: the count
> argument is an int and not a size_t.
While MPI-2 was being written, there were furious debates over whether
to provide class library functionality for MPI or whether
"minimialistic" functionality should be provided. As is evident, the
"minimalistic" arguments won, based on the fact that the language
bindings of a standard should impose at little additional abstractions
over the base standard. Specifically, using the minimalistic approach,
you can build a wide range of class libraries on top of it.
Standardizing one class library, however, would limit the C++
abstractions that could be layered on top of it [much more so than a
minimalistic approach].
The thought with virtual classes was that, for example, you could
provide derivative objects that provided additional send/recv functions
for new C++ types. For example, have a different namespace that has a
Intra::Comm class that dervied from MPI::Intra::Comm, but had a Send
method for vector<int>.
Clearly, you don't have to do it that way, but back in 1996, we were
trying to anticipate how class library authors might want to use the
C++ MPI interface. 8 years is a long time for a language and the
available compilers to evolve. We probably didn't get everything
right, but we weren't able to predict the future, either. :-)
> In short, I think that
> the C++ interface could use an overhaul; maybe a mpi2
> namespace?
Mentions of MPI-3 are dreaded among those who used to be in the Forum.
;-)
> jsquyres> something layered on top of MPI. Hence, your
> jsquyres> function will probably eventually resolve down
> jsquyres> to an MPI_SEND that will do the actual sending
> jsquyres> of the correct datatype. With a bit of
> jsquyres> cleverness, the function could probably be
> jsquyres> inlined, and there would be little performance
> jsquyres> overhead (although going through the iterators
> jsquyres> might take some time... you'd have to evaluate
> jsquyres> that for your own requirements/needs).
>
> Sending the data takes eons anyway, at least compared with a
> function call or going through iterators.
This is true on slow networks, but is not necessarily true for shared
memory or OS-bypass networks such as Infiniband, Myrinet, or Quadrics.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
