[Mpi3-hybridpm] Ticket 217 proposal document updated

Jim Dinan dinan at mcs.anl.gov
Mon Jan 30 13:56:38 CST 2012


Hi Doug,

I think we can probably get rid of the barrier, it seems to suggest a 
stronger requirement (sync-first) for helper threads.  MPI could 
implement this behavior internally in leave if it's required by the 
implementation.

This copy code also seems a bit verbose to me:

# pragma omp for
for (i = 0; i < count; i++) {
   sendbuf[i] = recvbuf[i];
}

Is the idea that this would be faster than a serial memcpy?  We could 
simplify the example by just calling memcpy.  I guess we would need to 
add a barrier, though.

"i" needs to be made thread private (declare in parallel region?).

"double myval = 0.0" should be moved to the top of the block for C89 
compliance.

oldval and newval are shared, "oldval = newval" will have 
race/consistency problems.  Should these also be thread private?

"nobreak" adds a lot of lines of code and not a lot of information to 
the example.  I think it would be better to point out in a caption that 
you could pass the "nobreak" info key and shorten the example by leaving 
out all the Info wrangling code.

Suggest s/count/COUNT/ so that it looks like a constant in the array 
declarations.

Have you tried compiling/running this with no-op/barrier implementations 
of the helper threads functions?

  ~Jim.

On 1/30/12 1:32 PM, Douglas Miller wrote:
> The "#pragma omp for" does a barrier at the end of the block (since we
> did not specify "nowait"), so I don't think it is required.
>
>
> _______________________________________________
> Douglas Miller BlueGene Messaging Development
> IBM Corp., Rochester, MN USA Bldg 030-2 A401
> dougmill at us.ibm.com Douglas Miller/Rochester/IBM
>
> Inactive hide details for Jim Dinan ---01/30/2012 12:44:47 PM---Jim
> Dinan <dinan at mcs.anl.gov>Jim Dinan ---01/30/2012 12:44:47 PM---Jim Dinan
> <dinan at mcs.anl.gov>
>
>     *Jim Dinan <dinan at mcs.anl.gov>*
>     Sent by: mpi3-hybridpm-bounces at lists.mpi-forum.org
>
>     01/30/2012 12:38 PM
>     Please respond to
>     mpi3-hybridpm at lists.mpi-forum.org
>
> 	
>
> To
> 	
>
>     mpi3-hybridpm at lists.mpi-forum.org,
>
>
> cc
> 	
>
> Subject
> 	
>
>     Re: [Mpi3-hybridpm] Ticket 217 proposal document updated
>
> 	
>
>
> Hi Doug,
>
> In Example 12.3, the "#omp barrier" should be required to ensure that
> all threads have finished updating sendbuf and reading recvbuf before
> the Allreduce.
>
> ~Jim.
>
> On 1/30/12 8:27 AM, Douglas Miller wrote:
>  > I've updated the PDF in Ticket 217 based on latest comments. Please
>  > review the text and send me comments. This is an attempt to make the
>  > concept easier to follow by describing in terms of a "team epoch".
>  >
>  > thanks,
>  > _______________________________________________
>  > Douglas Miller BlueGene Messaging Development
>  > IBM Corp., Rochester, MN USA Bldg 030-2 A401
>  > dougmill at us.ibm.com Douglas Miller/Rochester/IBM
>  >
>  >
>  > _______________________________________________
>  > Mpi3-hybridpm mailing list
>  > Mpi3-hybridpm at lists.mpi-forum.org
>  > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm
> _______________________________________________
> Mpi3-hybridpm mailing list
> Mpi3-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm
>
>
>
>
> _______________________________________________
> Mpi3-hybridpm mailing list
> Mpi3-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm



More information about the mpiwg-hybridpm mailing list