>>>>> 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. In short, I think that
the C++ interface could use an overhaul; maybe a mpi2
namespace?
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.
jsquyres> The OOMPI project took a few steps in the
jsquyres> direction of a class library for MPI several
jsquyres> years ago (1996-ish?), but didn't do anything
jsquyres> like this. Both the C++ language itself and
jsquyres> the quality of compilers available have
jsquyres> improved significantly since then.
Yep I have seen it, but never gotten around to using it.
[...]
--
Fredrik Hedman
|
