[mpich-discuss] MPI_Allgatherv complexity

[Justin Luitjens]

Actually I just realized I was wrong with what I said.  Our code has a lot
of variation but the allgather test that I wrote and timed in the graph I
attached will only have a single element of variation between each process.
Is there an environment variable I can set to force either the ring
algorithm or the recursive doubling algorithm to compare the times?

Justin

On Mon, Nov 2, 2009 at 5:17 PM, Justin Luitjens <luitjens at gmail.com> wrote:

> There is likely a decent amount of variance in the distribution.
>
>
> On Mon, Nov 2, 2009 at 5:15 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
>
>>
>> On 11/02/2009 06:11 PM, Justin Luitjens wrote:
>> > Here is a graph of the time for an allgather as a function of message
>> > size.  We would like to scale up to 98K processors but as you can see
>> > the time for all gather dramatically increases at 49K processors.  At
>> > 98K the time increases by around a factor of 4 for the few datapoints
>> > that I have tested (they are not in the graph).
>>
>> What's the message size pattern like? Is everyone using about the same
>> size messages, or is there a lot of skew? For the second case, we added
>> a new algorithm to fix this performance issue, though I'm not sure Cray
>> picked it up yet.
>>
>>  -- Pavan
>>
>> --
>> Pavan Balaji
>> http://www.mcs.anl.gov/~balaji <http://www.mcs.anl.gov/%7Ebalaji>
>> _______________________________________________
>> mpich-discuss mailing list
>> mpich-discuss at mcs.anl.gov
>> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20091102/559e6026/attachment.htm>