[Mpi3-abi] For the April MPI Forum Meeting

[Supalov, Alexander]

Hi,

The purpose of having as much input data as possible before deciding
whether and how to proceed is to not miss a potentially important data
point.

In this vein, I'd love to see some MPICH1 and HP MPI data there. That,
with the data already in the spreadsheet, would most likely cover 99% of
the currently targeted platforms (IA32/Intel64/Linux/Windows).

A split into several files would make sense if we had dozens of actively
contributing members. At the moment we are blessed with but a few.

Best regards.

Alexander 

-----Original Message-----
From: mpi3-abi-bounces_at_[hidden]
[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres
Sent: Friday, April 25, 2008 12:41 PM
To: MPI 3.0 ABI working group
Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting

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
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.