This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
in our code we use a very short front-end program to drive a larger set of
codes that do our calculations. Right in the beginning of the front-end, we
have an if() statement such that only the rank 0 front-end does something,
and the other ranks go right away to an MPI_Barrier() statement, waiting for
the rank 0 front-end to finish. The rank 0 front-end then goes ahead and
does its thing by calling the other codes with MPI_Comm_spawn().
We noticed that the rank > 0 copies of the front-end consume a lot of CPU
while they are waiting at the MPI_Barrier(). This is obviously not what we
had intended. From previous discussion on this list I understand that the
CPU consumption stems from the aggressive polling frequency of the
MPI_Barrier() function. While I understand that there are a lot of
situations where a high polling frequency in MPI_Barrier() is useful, the
situation we are in is not one of them.
Is our master and slave programming model such an unusual way of using MPI?