Yeah, I know what you mean about if you have to use a 'all to all'
use MPI_Alltoall() don't roll your own.
So on paper, alltoall at first glance appears to be: n*(n-1) -> n^2-
n -> n^2 (for large n).
Allreduce appears to be simplest, n point to points followed by a
bcast(). Which can be simplified to gather + bcast.
Last I knew MPI_Bcast() was log(n) and gather is (n). So for
allreduce I get:
n+log(n)
I guess I am confused how to get alltoall() down from n^2.
Thanks.
Brock Palen
Center for Advanced Computing
bro...@umich.edu
(734)936-1985
On Mar 12, 2008, at 6:05 PM, Aurélien Bouteiller wrote:
If you can avoid them it is better to avoid them. However it is always
better to use a MPI_Alltoall than coding your own all to all with
point to point, and in some algorithms you *need* to make a all to all
communication. What you should understand by "avoid all to all" is not
avoid MPI_alltoall, but choose a mathematic algorithm that does not
need all to all.
The algorithmic complexity of AllReduce is the same as AlltoAll.
Aurelien
Le 12 mars 08 à 17:01, Brock Palen a écrit :
I have always been told that calls like MPI_Barrior() MPI_Allreduce()
and MPI_Alltoall() should be avoided.
I understand MPI_Alltoall() as it goes n*(n-1) sends and thus grows
very very quickly. MPI_Barrior() is very latency sensitive and
generally is not needed in most cases I have seen it used.
But why MPI_Allreduce()?
What other functions should generally be avoided?
Sorry this is kinda off topic for the list :-)
Brock Palen
Center for Advanced Computing
bro...@umich.edu
(734)936-1985
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
