[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