[mpich-discuss] Better alternatives of MPI_Allreduce()
Benson Muite
benson_muite at emailplus.org
Tue May 5 06:20:57 CDT 2020
>> >
>> > Hi Hitesh,
>> >
>> > What hardware are you running on and what is the interconnect?
>
> Right now I am using a cluster.
What is the interconnect?
>
>> > Have you tried changing any of the MPI settings?
>
> What do you mean by MPI settings?
Given your comment on the barrier, this is probably not so useful at the moment.
>
>> > Can the reduction be done asynchronously?
>
> I did not get your question.
For example using a non blocking all reduce:
https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report/node135.htm
>
>> >
>> > Regards,
>> > Benson
>>
>> Also, is your work load balanced? One way to check this might be to place a barrier just before the all-reduce call. If the barrier ends up taking most of your time, then it is likely you will need to determine a better way to distribute the computational work.
>
> Thanks for your response.
>
> Yes, you are right. I have put barrier just before Allreduce and out of the total time consumed by Allreduce, 79% time is consumed by the barrier. But my computational work is balanced. Right now, I have distributed 97336 cells among 24 processors and maximum and minimum cell distribution among all processors is 4057 and 4055 respectively which is not too bad. Is there any solution to get rid of this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20200505/b2c627af/attachment.html>
More information about the discuss
mailing list