[Mpi3-abi] For the April MPI Forum Meeting

[Erez Haba]

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