[Mpi3-bwcompat] Teleconf tomorrow?

Jeff Squyres jsquyres jsquyres at [hidden]
Fri Oct 15 05:32:04 CDT 2010



It would also be weird that alltoall takes int but ialltoall takes MPI-count. 

Sent from my PDA. No type good. 

On Oct 15, 2010, at 12:40 AM, "Fab Tillier" <ftillier_at_[hidden]> wrote:

> Quincey Koziol wrote on Thu, 14 Oct 2010 at 20:44:23
> 
>> On Oct 14, 2010, at 2:29 PM, Jeff Squyres wrote:
>> 
>>> On Oct 14, 2010, at 2:54 PM, Fab Tillier wrote:
>>> 
>>>> 2. Add just the bare minimum, leverage datatypes to work around
>>>> counts.  Note that this requires introducing w versions of v
>>>> collective APIs, to allow for different types (since the v functions
>>>> allow different counts from each participant.)
>>> 
>>> This option also includes the "output" functions, right?
>> 
>>    Yes, that's the basic idea.
>> 
>>    BTW, I think this is a perfectly acceptable solution (as much as
>> I'd like a blue pony :-).  Fab was talking about just doing this, along
>> with introducing MPI_Count, etc. for _future_ routines and getting a
>> consensus from the forum that all future routines would use MPI_Count,
>> etc.  Since it only duplicates a few functions now (they necessary ones
>> to get the I/O and datatype routines working with large counts), it
>> satisfies a lot of "agile" design guidelines and I think it might be a
>> very reasonable thing to do.
> 
> I don't know if the forum would go for defining new functions to use MPI_Count only.  I think it's a brilliant idea personally, though one could make the argument that requiring something like MPI_IAlltoallv to take arrays of MPI_Count when taking arrays of int would be half the size would be detrimental to performance.
> 
> -Fab
> 
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat



More information about the Mpi3-bwcompat mailing list