[Beowulf] mpich future
rross at mcs.anl.gov
Mon Feb 7 11:07:43 PST 2005
You are right that there are a decent number of MPI implementations out
there, all with their pros and cons. There is no "best" implementation,
and in fact I would say that the existence of multiple implementations is
helpful to the community by providing (a) multiple takes on how to build
these libraries, and (b) competition between the implementations to be the
"best" at what they think is most important.
I'm not sure what you mean by "trouble with the different standards"? All
implementations should at this point be striving for complete 2.0
compliance, and there are very few things from 1.x that won't work in a
2.0 compliant system (the group defining the standard went to great pains,
as do the developers, to maintain this compatibility). So you shouldn't
need those preprocessor variables. What functionality are you finding
that you need to test for?
I would say that at this time MPICH2 has as much influence as any
implementation, because it is being used as the basis for multiple Cray
platform implementations, the IBM BG/L implementation, the OSU IB
implementation, and of course as-is on Windows, OS X, and Linux clusters.
Of course I am part of the MPICH2 team, so I am biased :).
OpenMPI will undoubtedly be an influential member of the MPI community
once the software is made widely available. That group also has a
collection of developers with very good track records in this area, and I
look forward to being able to compare and contrast the designs and
The big buzz in the MPI world right now is fault tolerance. I think this
topic is going to be a hot one for some time, and there are definitely
differences of opinion on how the MPI implementation should deal with
faults and to what degree and how users should be made aware of failures,
both transient and catastrophic.
Less visible, but at least as important, is figuring out how best to
implement the one-sided (RMA) operations that are part of MPI 2.0. My
colleague Rajeev Thakur has (in my opinion) done an excellent job of
these, building in part on concepts from the BSP system of old.
Figuring out how to make collectives as efficient as possible on new, very
large machines is also extremely important for those that have access to
these new machines. Gheorghe Almasi from IBM had an excellent paper
discussing collectives on the BG/L machine in last year's EuroPVM/MPI
Rolf Rabenseifner and Jesper Traff both presented improvements to
collective algorithms as well. These two were iterative improvements I'd
say, so less exciting in some sense, but it is critical that we make these
algorithms as efficient as possible, given the scale of upcoming systems.
If you are really interested in what is happening in MPI, the best place
by far to look is the EuroPVM/MPI series of conferences and their
proceedings. This is where everyone that is serious about MPI
implementations is publishing and going to talk with colleagues, and every
year the conference attendee list is literally a list of the most
knowledgable MPI developers in the world (and hangers-on such as myself).
Rob Ross, Mathematics and Computer Science Division, Argonne National Lab
On Mon, 7 Feb 2005, rene wrote:
> there are many mpi implementations out there, but which one ist "the best"?
> As far as I know, there are commercial prodcuts which support different
> hardware in one library (eg myrinet + ethernet). Which is a nice feature.
> Is there a working mpich which unites the common channels?
> Score did that once, but it's a year ago, since I've worked with it.
> In addition to that I've ran into trouble with the different standarts (1.2,
> It seems to me that Openmpi gets more influence. Is that right?
> I dont feel like put 20 different preprocessor variables on my applications,
> #if MPI_VERSION > 1
> for each of that implementation.
> So my question is:
> In which direction goes mpi tomorrow?
> Rene Storm
More information about the Beowulf