[Mpi3-abi] For the April MPI Forum Meeting

[Jeffrey S. Brown]

Well, if the goal is a common ABI then we have to expose the details in
order to put together a proposal for the group.  I don't see any other way
to do it.

As for the spreadsheet ...

One way to do it would be to assign an "owner" for each of the columns on
the spreadsheet.  I will do the integration.  Let's discuss at the WG
session next week.

I'd like to start getting into discussion of the ABI column.  We should
have enough data to get that rolling.  Perhaps we will have something to
propose at the next meeting (although this seems to pop up on everyones
radar a week prior to the meeting - myself included).

Jeff

> 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
>
> _______________________________________________
> mpi3-abi mailing list
> mpi3-abi_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi
>