On Sep 2, 2008, at 7:25 PM, Vincent Rotival wrote:
I think I already read some comments on this issue, but I'd like to
know of latest versions of OpenMPI have managed to solve it. I am
now running 1.2.5
If I run a MPI program with synchronization routines (e.g.
MPI_barrier, MPI_bcast...),
Jeff Squyres wrote:
On Sep 2, 2008, at 7:25 PM, Vincent Rotival wrote:
I think I already read some comments on this issue, but I'd like to
know of latest versions of OpenMPI have managed to solve it. I am
now running 1.2.5
If I run a MPI program with synchronization routines (e.g.
MPI_b
Eugene Loh wrote:
Jeff Squyres wrote:
On Sep 2, 2008, at 7:25 PM, Vincent Rotival wrote:
I think I already read some comments on this issue, but I'd like to
know of latest versions of OpenMPI have managed to solve it. I am
now running 1.2.5
If I run a MPI program with synchronization r
Vincent Rotival wrote:
The solution I retained was for the main thread to isend data
separately to each other threads that are using Irecv + loop on
mpi_test to test the finish of the Irecv. It mught be dirty but works
much better than using Bcast
Thanks for the clarification.
But this st
Eugene,
No what I'd like is that when doing something like
call mpi_bcast(data, 1, MPI_INTEGER, 0, .)
the program continues AFTER the Bcast is completed (so no control
returned to user), but while threads with rank > 0 are waiting in Bcast
they are not taking CPU resources
I hope it is
On Sep 3, 2008, at 6:11 PM, Vincent Rotival wrote:
Eugene,
No what I'd like is that when doing something like
call mpi_bcast(data, 1, MPI_INTEGER, 0, .)
the program continues AFTER the Bcast is completed (so no control
returned to user), but while threads with rank > 0 are waiting in
Ok let's take the simple example here, I might have use wrong terms and
I apologize for it
While the rank 0 process is sleeping the other ones are in bcast waiting
for data
program test
use mpi
implicit none
integer :: mpi_wsize, mpi_rank, mpi_err
integer :: data
call mpi_init(mpi_er
This program is 100% correct from MPI perspective. However, in Open
MPI (and I think most of the others MPI), a collective communication
is something that will drain most of the resources, similar to all
blocking functions.
Now I will answer to your original post. Using non blocking
commu
Vincent
1) Assume you are running an MPI program which has 16 tasks in
MPI_COMM_WORLD, you have 16 dedicated CPUs and each task is single
threaded. (a task is a distinct process, a process can contain one or more
threads) The is the most common traditional model. In this model, when a
task makes
I hope the following helps, but maybe I'm just repeating myself and Dick.
Let's say you're stuck in an MPI_Recv, MPI_Bcast, or MPI_Barrier call
waiting on someone else. You want to free up the CPU for more
productive purposes. There are basically two cases:
1) If you want to free the CPU u
As usual, Dick is much more eloquent than me. :-)
He also correctly pointed out to me in an off-list mail that in my
first reply, I casually used the internal term "blocking progress" and
probably sowed some of the initial seeds of confusion in this thread
(because "blocking" has specific
11 matches
Mail list logo
