[Mpi3-abi] For the April MPI Forum Meeting

[Supalov, Alexander]

Hi,

I've updated Jeff's file in the Wiki: some formatting, some typos fixed (in red), etc.

Best regards.

Alexander 

-----Original Message-----
From: Supalov, Alexander 
Sent: Friday, April 25, 2008 8:12 PM
To: 'MPI 3.0 ABI working group'
Subject: RE: [Mpi3-abi] For the April MPI Forum Meeting

Hi,

The initial ABI proposal draft (see http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/AbiWikiPage/MPI%20ABI%200.4.doc) cites Bill Gropp's paper to introduce the MPI constant hierarchy basing on when the items are/should be defined according to the standard. We can use that hierarchy to split all ABI entities into groups.

Here is the pertinent excerpt:

-	Compatible MPI data entities
        o	Compile-time values
                §	Used in declarations (MPI_MAX_ERROR_STRING, etc.)
                §	Other (MPI_ANY_SOURCE, MPI_ERR_TRUNCATE, etc.)
        o	Init-time constants (MPI_INT, etc.)
        o	Opaque objects (MPI_Comm, MPI_Datatype, etc.)
        o	Defined objects (MPI_Status)
        o	Defined pointers (MPI_BOTTOM, MPI_STATUS_NULL, etc.)

And while we're so focused on the mpi.h contents, I can't help reiterating that this is but a part of the ABI matter. The following is no less important for the whole thing to work:

-	Uniform approach to the macro implementation of certain functions (MPI_Wtime, MPI_Wtick, handle conversion calls, possibly others)
-	Similar calling convention
        o	Argument order and size
        o	Stack frame management policy
        o	Return address storage and handling
        o	Function call and return handling 
-	Common linkage convention
        o	Library file format
        o	MPI library name
        o	MPI library path resolution mechanism
        o	System library dependency resolution

Best regards.

Alexander 

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

I think that we need enough data to put the constants into classes of constants that are different from one implementation to the other (examples for a classes, are "handles", "datatype"). Once done, we'll be able to understand the differences in the different implementations (approach) and in the different platforms.  This will enable us to come up with reasonable suggestion for the ABI constants.

I think that putting the constants in different spreadsheet (split by os/cpu) is reasonable.

Thanks,
.Erez

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

On Apr 25, 2008, at 8:32 AM, Supalov, Alexander wrote:

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

I'm all for having enough data points.  I was questioning how many we
need -- it just looked like we we diverging into the "need dozens of
datapoints" realm.  If we're not, no problem.

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

The wiki has no "lock" feature.  SVN does, but we don't really have a
common SVN.

This is the canonical problem with binary formats -- more power in the
binary-based tool (excel), but less collaboration ability.  I suppose
a sharepoint server would work...?  But [I'm assuming] that would be a
nightmare of licensing and access control setup.

We could use a tex-based format (latex?) that allows merge
capabilities, or use the wiki text format (but wikis don't handle
simultaneous editing nicely -- someone inevitably "loses", rather than
having the ability to merge their new text in).

Splitting into mutliple files, each with a discrete author, might
still be the best solution.  [shrug]


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