Re: [mpi-21] ABI - call for working group

[Greg Bronevetsky <bronevetsky1@xxxxxxxx>]

> We aren't talking about ABI-related bugs or functionality issues,
> we're talking about MPI implementation bugs combined with
> non-standard-conforming programs ("my program works with some other
> MPIs, so it must be correct!"). And yes, an ABI doesn't make either
> issue go away, but it can make testing with many MPIs much easier.
>
> BTW, in the MorphMPI scenario, who is going to support MorphMPI? MPI
> vendors are going to revolt at the thought of being on the hook for
> bugs caused by software layers they don't control. And ISVs aren't
> going to like that situation, either. I think the most likely outcome
> is an even more complicated compatibility matrix, where MPI vendors
> and ISVs will require particular versions of the MorphMPI. Yuck.

Fair enough. I don't know how this tug-of-war is going to play out. 
My expectation is that morphing layers will need little updating 
after the initial well-tested releases because the MPI spec changes 
rarely and MPI implementations don't come out with ABI-related 
updates very often. As such, morphing layers should be a rather solid 
part of the software stack. However, this is a hard one to judge.

I think that the best way to poll the community about this is to 
separate the parts of the proposal related to Application-MPI 
interactions from the rest of it. This way the community can make an 
intelligent choice of what they prefer. With the Application-MPI 
proposal they can choose between morphing layers and standardization. 
With the rest of the proposal they can choose between standardization 
and nothing. Since the choices are different, the two parts need to 
be separated.

Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1@xxxxxxxx