[Beowulf] mpich future

[Rob Ross]

Hi Rene,

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 
resulting performance.

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 
conference.

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).

Regards,

Rob
---
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, 
> 2.0). 
> It seems to me that Openmpi gets more influence. Is that right?
> 
> I dont feel like put 20 different preprocessor variables on my applications, 
> like
> #if MPI_VERSION > 1
> for each of that implementation.
> 
> So my question is:
> In which direction goes mpi tomorrow?
> 
> Cu
> 
> -- 
> Rene Storm
> @Cluster