Broadcast is collective but not necessarily synchronous in the sense you imply. If you broadcast message size under the eager limit, the root may return before any non-root processes enter the function. Data transfer may happen prior to processes entering the function. Only rendezvous forces synchronization between any two processes but there may still be asynchrony between different levels of the broadcast tree.
Jeff On Fri, Oct 20, 2017 at 3:27 PM Konstantinos Konstantinidis < kostas1...@gmail.com> wrote: > Hi, > > I am running some tests on Amazon EC2 and they require a lot of > communication among m3.large instances. > > I would like to give you an idea of what kind of communication takes > place. There are 40 m3.large instances. Now, 28672 groups of 5 instances > are formed in a specific manner (let's skip the details). Within each > group, each instance broadcasts some unsigned char data to the other 4 > instances in the group. So within each group, exactly 5 broadcasts take > place. > > The problem is that if I increase the size of the group from 5 to 10 there > is significant delay in terms of transmission rate while, based on some > theoretical results, this is not reasonable. > > I want to check if one of the reasons that this is happening is due to the > time needed for the instances to synchronize when they call MPI_Bcast() > since it's a collective function. As far as I know, all of the machines in > the broadcast need to call it and then synchronize until the actual data > transfer starts. Is there any way to measure this synchronization time? > > The code is in C++ and the MPI installed is described in the attached file. > _______________________________________________ > users mailing list > users@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/users -- Jeff Hammond jeff.scie...@gmail.com http://jeffhammond.github.io/
_______________________________________________ users mailing list users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/users
