[Mpi3-abi] For the April MPI Forum Meeting

[Jeff Squyres]

On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote:

> I've reviewed the current spreadsheet. Note that according to our
> current observations, 64-bit Linux column covers Itanium Linux as  
> well,
> as far as the contents of the MPICH2 mpi.h is concerned. I take this  
> as
> an indication that we should not forget that ABI is more than mpi.h,  
> and
> that we should be very specific in the platform description.
>
> Also, we might want to split Linux and Windows into different  
> subsheets.
> Indeed, splitting into 32- and 64-bit might be helpful as well, as  
> soon
> as the table becomes densely populated. I think this is something we
> should discuss when we see a joint ABI emerging.

What is the goal for all of this analysis?  I think we can already  
tell that:

- many MPI implementations have different fixed values for the same  
MPI constants/etc.
- some MPI implementations have run-time determined values (e.g.,  
pointers)
- some MPI implementations change values/types based on the compiler 
+platform that they are operating on

Do we really need to make a comprehensive list of all MPI's on all  
compiler+platforms to see these trends?  Is there specific data that  
would be gleaned from these vs. seeing a representative sample?

(just trying to understand the purpose of the ever-expanding  
spreadsheet)

> I have a process question here: how do we prevent multiple updates
> running into each other, or overwriting each other accidentally? Is
> there a check-in/out feature in Wiki, or should we introduce a manual
> lock? Say, a file with a well known name to create before editing and
> delete afterwards? The name of the creator would show who's holding  
> the
> lock. The modification date of the main file would show whether the  
> copy
> you're working with is still actual.

How about creating separate spreadsheets, one for each MPI  
implementation?  This would allow for more-or-less independent updates.

At some point in the future (when most changes have been complete),  
they can be [re-]merged back into one spreadsheet.


-- 
Jeff Squyres
Cisco Systems