November 2009 - mpiwg-hybridpm - mailman3.cels.anl.gov

Re: [Mpi3-hybridpm] MPI3 Hybrid telecon tomorrow
by Snir, Marc 24 Nov '09

24 Nov '09

I made it to the call -- but after you people ended it -- sorry about that. On Nov 24, 2009, at 11:09 AM, Pavan Balaji wrote: > > On 11/24/2009 11:08 AM, Pavan Balaji wrote: >> We canceled today's telecon as Marc couldn't make it to the call, and >> the only discussion item we had was his proposal. We should try to >> synchronize next week to clean up some of the issues brought up in the >> proposal. > > Sorry, I meant we should synchronize on the next call 2 weeks from now, > not next week. > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji Marc Snir 4323 Siebel Center, 201 N Goodwin, IL 61801 Tel (217) 244 6568 Web http://www.cs.uiuc.edu/homes/snir

1 0

Re: [Mpi3-hybridpm] MPI3 Hybrid telecon tomorrow
by Pavan Balaji 24 Nov '09

24 Nov '09

On 11/24/2009 11:08 AM, Pavan Balaji wrote: > We canceled today's telecon as Marc couldn't make it to the call, and > the only discussion item we had was his proposal. We should try to > synchronize next week to clean up some of the issues brought up in the > proposal. Sorry, I meant we should synchronize on the next call 2 weeks from now, not next week. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-hybridpm] MPI3 Hybrid telecon tomorrow
by Pavan Balaji 24 Nov '09

24 Nov '09

All, We canceled today's telecon as Marc couldn't make it to the call, and the only discussion item we had was his proposal. We should try to synchronize next week to clean up some of the issues brought up in the proposal. Thanks, -- Pavan On 11/23/2009 09:06 AM, Pavan Balaji wrote: > Folks, > > This is a reminder for the hybrid telecon tomorrow (11/24). We'll mainly discuss the issues that were brought up during the last MPI Forum meeting with respect to the endpoint proposal. If there are other items you'd like added to the agenda, please send me a note. > > The telecon information is available on the hybrid wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Hybrid > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

[Mpi3-hybridpm] MPI3 Hybrid telecon tomorrow
by Pavan Balaji 23 Nov '09

23 Nov '09

Folks, This is a reminder for the hybrid telecon tomorrow (11/24). We'll mainly discuss the issues that were brought up during the last MPI Forum meeting with respect to the endpoint proposal. If there are other items you'd like added to the agenda, please send me a note. The telecon information is available on the hybrid wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Hybrid -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

[Mpi3-hybridpm] Face-to-face meeting notes
by Pavan Balaji 16 Nov '09

16 Nov '09

Folks, I've added some notes from the MPI Forum meeting last week on the wiki (https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Hybrid/notes-2009-11-…) Please check for correctness. There are a bunch of issues that require discussion. We'll need to put some of them on the agenda for next week's telecon. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-hybridpm] new version of proposal
by Snir, Marc 12 Nov '09

12 Nov '09

On Nov 12, 2009, at 11:27 AM, Joe Ratterman wrote: Marc, I had a few clarification questions that I also wanted to ask about the V3 proposal. >From section 1.4: The binding of threads to MPI endpoints can change during program execution, but is explicit, and is expected to change rarely (hence need not be a fast operation). This choice allows endpoint creation to precede thread spawning; it is not expected to add significant complexity to the implementation. What does this imply about the case of a thread that attaches to an endpoint and then spawns a thread? Is the new thread also attached to the same endpoint? This would have obvious negative issues in MPI_THREAD_FUNNELED, and would also complicate use of thread-local-storage in the implementation to track the selected endpoint. My opinion would be that new threads should be defined to be detached from endpoints. I agree -- will clarify >From section 2.2: ...it will generate a communicator MPI_COMM_EWORLD that includes all endpoints and has num_endpoints endpoints at each calling process. Upon first read, my coworkers and I are often confused by this sentence, which seems to say that num_endpoints must be the same everywhere. By now I'm pretty sure that isn't the case, so I'm hoping that it can be reworded to make that more clear. Maybe, "...it will generate a communicator MPI_COMM_EWORLD that includes all endpoints and is of the size of the sum of the unique num_endpoints supplied by each calling process." OK What is the mapping between the ranks of endpoints in MPI_COMM_PROCESS and the index of the endpoint handle in the array returned from MPI_Endpoint_create? I would suggest that it be clearly stated that MPI_Thread_attach(array[X]) will always result in the thread becoming rank X in MPI_COMM_PROCESS. It might also help to establish a fixed mapping between WORLD, EWORLD, and PROCESS, but that seems less important. Yes -- will clarify I noticed that the example in section 5.3 uses MPI_Endpoint_register(). Is it supposed to be MPI_Thread_attach? Thanks -- incompletely propagated change Thanks, Joe Ratterman Thanks On Mon, Nov 9, 2009 at 10:43 PM, Snir, Marc <snir(a)illinois.edu<mailto:[email protected]>> wrote: Is appended on the wiki. I believe (hope) that it addresses all comments I received on the previous version. I hope to post slides tomorrow. Marc Snir Michael Faiman and Saburo Muroga Professor Department of Computer Science, University of Illinois at Urbana Champaign 4323 Siebel Center, 201 N Goodwin, IL 61801 Tel (217) 244 6568 Web http://www.cs.uiuc.edu/homes/snir _______________________________________________ Mpi3-hybridpm mailing list Mpi3-hybridpm(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm <ATT00001..txt> Marc Snir 4323 Siebel Center, 201 N Goodwin, IL 61801 Tel (217) 244 6568 Web http://www.cs.uiuc.edu/homes/snir

1 0

Re: [Mpi3-hybridpm] new version of proposal
by Joe Ratterman 12 Nov '09

12 Nov '09

Marc, I had a few clarification questions that I also wanted to ask about the V3 proposal. >From section 1.4: > The binding of threads to MPI endpoints can change during program > execution, but is explicit, and is expected to change rarely (hence need not > be a fast operation). This choice allows endpoint creation to precede > thread spawning; it is not expected to add significant complexity to > the implementation. > What does this imply about the case of a thread that attaches to an endpoint and then spawns a thread? Is the new thread also attached to the same endpoint? This would have obvious negative issues in MPI_THREAD_FUNNELED, and would also complicate use of thread-local-storage in the implementation to track the selected endpoint. My opinion would be that new threads should be defined to be detached from endpoints. >From section 2.2: > ...it will generate a communicator MPI_COMM_EWORLD that includes all > endpoints and has num_endpoints endpoints at each calling process. > Upon first read, my coworkers and I are often confused by this sentence, which seems to say that num_endpoints must be the same everywhere. By now I'm pretty sure that isn't the case, so I'm hoping that it can be reworded to make that more clear. Maybe, "...it will generate a communicator MPI_COMM_EWORLD that includes all endpoints and is of the size of the sum of the unique num_endpoints supplied by each calling process." What is the mapping between the ranks of endpoints in MPI_COMM_PROCESS and the index of the endpoint handle in the array returned from MPI_Endpoint_create? I would suggest that it be clearly stated that MPI_Thread_attach(array[X]) will always result in the thread becoming rank X in MPI_COMM_PROCESS. It might also help to establish a fixed mapping between WORLD, EWORLD, and PROCESS, but that seems less important. I noticed that the example in section 5.3 uses MPI_Endpoint_register(). Is it supposed to be MPI_Thread_attach? Thanks, Joe Ratterman On Mon, Nov 9, 2009 at 10:43 PM, Snir, Marc <snir(a)illinois.edu> wrote: > Is appended on the wiki. I believe (hope) that it addresses all > comments I received on the previous version. > I hope to post slides tomorrow. > > > Marc Snir > Michael Faiman and Saburo Muroga Professor > Department of Computer Science, University of Illinois at Urbana > Champaign > 4323 Siebel Center, 201 N Goodwin, IL 61801 > Tel (217) 244 6568 > Web http://www.cs.uiuc.edu/homes/snir > > > > > > > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm >

1 0

Re: [Mpi3-hybridpm] Clarification on single-communication multiple-threads in latest proposal (9-nov-2009)
by Douglas Miller 12 Nov '09

12 Nov '09

I like the idea of making helper threads exposed to the application. But I'm still not clear on just how a communication would be performed. Consider an MPI_Allreduce that splits the operation into 4 units of work, each of which can be performed on separate threads, in parallel. In that case, I envision two possible scenarios: 1) One thread attaches to endpoint "A" normally, and calls MPI_Allreduce. The allreduce appends units of work to endpoints A, B, C, and D. Then 3 other threads attach to endpoints B, C, and D as "helpers" and the allreduce is performed and completed. 2) One thread attaches to endpoint "A" normally, and calls MPI_Allreduce. The allreduce appends all four units of work to endpoint A. The 3 other threads attach to endpoint A as "helpers". All four threads pick up a unit of work each, and the allreduce is performed and completed. The problem I see with option 1 is that it allows for units of work to appear unexpectedly on endpoints, which I think requires all endpoints to have helper threads attached at all times. This makes it difficult to have threads that transition between compute and communication phases. It also seems strange to have a unit of work being performed on an endpoint that has nothing to do with the "rank" associated with that endpoint. The problem I see with option 2 is that it requires endpoints to have a notion of "depth", or how many helper threads should be attached. It makes it less clear just why multiple endpoints are needed, and complicates how the messaging layers would divide up hardware resources since each helper thread would tend to want separate hardware resources, meaning a single endpoint would represent multiple hardware channels, each of which could be used independently for communication. "Snir, Marc" <snir(a)illinois.ed u> To Sent by: "mpi3-hybridpm(a)lists.mpi-forum.org" mpi3-hybridpm-bou <mpi3-hybridpm(a)lists.mpi-forum.org> nces(a)lists.mpi-fo cc rum.org Subject Re: [Mpi3-hybridpm] 11/11/2009 02:51 Clarification on PM single-communication multiple-threads in latest proposal (9-nov-2009) Please respond to mpi3-hybridpm@lis ts.mpi-forum.org On Nov 11, 2009, at 2:24 PM, Douglas Miller wrote: > > That's an interesting idea. How would a thread that attaches as a > "helper" > actually end up in the progress engine? Does the thread relinquish > control > when it attaches as a helper? Thus the MPI ADI would simply not > return but > rather call into a messaging layer progress loop? Yes -- that's the idea > And then the "detach all > helper threads" call would set some flag that causes the helper > threads to > break out of the loop and return? In this case, do you envision these > helper threads are all attached to the same endpoint, or are there > separate > endpoints? I envisage that a call by an application thread that is attached to a particular endpoint could detach all the helper threads from that particular endpoint. The call would return when the threads detached. This avoids the need for identifying thread ids elper threads could attach to different endpoints. > > > > > > > > "Snir, Marc" > <snir(a)illinois.ed > > u> To > Sent by: "mpi3-hybridpm(a)lists.mpi-forum.org > " > mpi3-hybridpm-bou <mpi3-hybridpm(a)lists.mpi-forum.org > > > nces(a)lists.mpi- > fo cc > rum.org > > Subject > Re: [Mpi3-hybridpm] > Clarification > 11/11/2009 05:05 on single-communication > AM multiple-threads in latest > proposal (9-nov-2009) > > Please respond to > mpi3-hybridpm@lis > ts.mpi-forum.org > > > > > > > Possible design with two new calls: > 1 A thread can attach as helper; > 2 an attached compute thread can detach all helper threads from it's > endpoint. > > Short iphone email > > > On Nov 11, 2009, at 12:19 AM, "Snir, Marc" <snir(a)illinois.edu> wrote: > >> I put a placeholder for this idea. It is easy for a thread to join as >> a helper. Harder for the apllication to request the thread back >> >> Short iphone email >> >> >> On Nov 10, 2009, at 3:03 PM, "Douglas Miller" <dougmill(a)us.ibm.com> >> wrote: >> >>> >>> I've been looking at the latest (v3) MPI3 Hybrid proposal and had a >>> question about support for parallelism within a communication. It >>> seems >>> that the direction we're going here is to have the application own >>> threads >>> and then "lend" them to the messaging software for use during >>> communications. This model works well in many situations, so it >>> seems worth >>> pursuing. One situation that it works well is when oversubscribing >>> processor resources is detrimental to performance, and so the >>> application >>> and messaging layers should be cooperative about using threads and >>> avoiding >>> oversubscription. >>> >>> The dimension of parallelism in question is where multiple threads >>> need to >>> participate in a single communication, either point-to-point or >>> collective. >>> The way in which those threads will participate is up to the >>> messaging >>> software, but some examples are: message striping across multiple >>> channels >>> of a network (or shared memory) and collectives that consist of >>> compound >>> communications operations that benefit from multiple threads each >>> performing a role in the larger collective. The question is, how >>> would this >>> be supported when using the model of threads, endpoints, and agents? >>> >>> Some examples might help illustrate the concerns. Consider a >>> blocking >>> collective that can benefit from parallelism. In order for the >>> application >>> to assign threads (or agents) to the collective, multiple threads >>> must call >>> into the messaging layer and indicate that they are part of the >>> particular >>> collective. This requires some sort of common identifier or other >>> mechanism >>> by which the messaging layer can identify these threads as being >>> part of >>> the same collective. Since the operation is blocking, there is no >>> "request" >>> or other object that can be used in a WAIT, so in order to ensure >>> all >>> threads are involved in the progress of the collective the >>> application must >>> arrange for each thread to call. Non-blocking calls also present >>> problems, >>> as there probably needs to be multiple requests generated which are >>> shared >>> among threads (agents) which all make progress individually. >>> >>> There are likely other ways to solve this, but the idea is to expose >>> this >>> dimension of parallelism such that applications can be written to >>> take >>> advantage of it. It would always be the case that a message layer >>> could >>> choose to use only one participant, the rest essentially performing >>> a NO-OP >>> (or barrier). It would also always be valid for an application to >>> use only >>> one thread, and not take advantage of possible parallelism. >>> >>> thanks, >>> >>> _______________________________________________ >>> Douglas Miller BlueGene Messaging Development >>> IBM Corp., Rochester, MN USA Bldg 030-2 A410 >>> dougmill(a)us.ibm.com Douglas Miller/Rochester/IBM >>> >>> _______________________________________________ >>> Mpi3-hybridpm mailing list >>> Mpi3-hybridpm(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm >> >> _______________________________________________ >> Mpi3-hybridpm mailing list >> Mpi3-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm > > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm > > > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm Marc Snir 4323 Siebel Center, 201 N Goodwin, IL 61801 Tel (217) 244 6568 Web http://www.cs.uiuc.edu/homes/snir _______________________________________________ Mpi3-hybridpm mailing list Mpi3-hybridpm(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm

1 0

Re: [Mpi3-hybridpm] Clarification on single-communication multiple-threads in latest proposal (9-nov-2009)
by Snir, Marc 11 Nov '09

11 Nov '09

On Nov 11, 2009, at 2:24 PM, Douglas Miller wrote: > > That's an interesting idea. How would a thread that attaches as a > "helper" > actually end up in the progress engine? Does the thread relinquish > control > when it attaches as a helper? Thus the MPI ADI would simply not > return but > rather call into a messaging layer progress loop? Yes -- that's the idea > And then the "detach all > helper threads" call would set some flag that causes the helper > threads to > break out of the loop and return? In this case, do you envision these > helper threads are all attached to the same endpoint, or are there > separate > endpoints? I envisage that a call by an application thread that is attached to a particular endpoint could detach all the helper threads from that particular endpoint. The call would return when the threads detached. This avoids the need for identifying thread ids elper threads could attach to different endpoints. > > > > > > > > "Snir, Marc" > <snir(a)illinois.ed > > u> To > Sent by: "mpi3-hybridpm(a)lists.mpi-forum.org > " > mpi3-hybridpm-bou <mpi3-hybridpm(a)lists.mpi-forum.org > > > nces(a)lists.mpi- > fo cc > rum.org > > Subject > Re: [Mpi3-hybridpm] > Clarification > 11/11/2009 05:05 on single-communication > AM multiple-threads in latest > proposal (9-nov-2009) > > Please respond to > mpi3-hybridpm@lis > ts.mpi-forum.org > > > > > > > Possible design with two new calls: > 1 A thread can attach as helper; > 2 an attached compute thread can detach all helper threads from it's > endpoint. > > Short iphone email > > > On Nov 11, 2009, at 12:19 AM, "Snir, Marc" <snir(a)illinois.edu> wrote: > >> I put a placeholder for this idea. It is easy for a thread to join as >> a helper. Harder for the apllication to request the thread back >> >> Short iphone email >> >> >> On Nov 10, 2009, at 3:03 PM, "Douglas Miller" <dougmill(a)us.ibm.com> >> wrote: >> >>> >>> I've been looking at the latest (v3) MPI3 Hybrid proposal and had a >>> question about support for parallelism within a communication. It >>> seems >>> that the direction we're going here is to have the application own >>> threads >>> and then "lend" them to the messaging software for use during >>> communications. This model works well in many situations, so it >>> seems worth >>> pursuing. One situation that it works well is when oversubscribing >>> processor resources is detrimental to performance, and so the >>> application >>> and messaging layers should be cooperative about using threads and >>> avoiding >>> oversubscription. >>> >>> The dimension of parallelism in question is where multiple threads >>> need to >>> participate in a single communication, either point-to-point or >>> collective. >>> The way in which those threads will participate is up to the >>> messaging >>> software, but some examples are: message striping across multiple >>> channels >>> of a network (or shared memory) and collectives that consist of >>> compound >>> communications operations that benefit from multiple threads each >>> performing a role in the larger collective. The question is, how >>> would this >>> be supported when using the model of threads, endpoints, and agents? >>> >>> Some examples might help illustrate the concerns. Consider a >>> blocking >>> collective that can benefit from parallelism. In order for the >>> application >>> to assign threads (or agents) to the collective, multiple threads >>> must call >>> into the messaging layer and indicate that they are part of the >>> particular >>> collective. This requires some sort of common identifier or other >>> mechanism >>> by which the messaging layer can identify these threads as being >>> part of >>> the same collective. Since the operation is blocking, there is no >>> "request" >>> or other object that can be used in a WAIT, so in order to ensure >>> all >>> threads are involved in the progress of the collective the >>> application must >>> arrange for each thread to call. Non-blocking calls also present >>> problems, >>> as there probably needs to be multiple requests generated which are >>> shared >>> among threads (agents) which all make progress individually. >>> >>> There are likely other ways to solve this, but the idea is to expose >>> this >>> dimension of parallelism such that applications can be written to >>> take >>> advantage of it. It would always be the case that a message layer >>> could >>> choose to use only one participant, the rest essentially performing >>> a NO-OP >>> (or barrier). It would also always be valid for an application to >>> use only >>> one thread, and not take advantage of possible parallelism. >>> >>> thanks, >>> >>> _______________________________________________ >>> Douglas Miller BlueGene Messaging Development >>> IBM Corp., Rochester, MN USA Bldg 030-2 A410 >>> dougmill(a)us.ibm.com Douglas Miller/Rochester/IBM >>> >>> _______________________________________________ >>> Mpi3-hybridpm mailing list >>> Mpi3-hybridpm(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm >> >> _______________________________________________ >> Mpi3-hybridpm mailing list >> Mpi3-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm > > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm > > > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm Marc Snir 4323 Siebel Center, 201 N Goodwin, IL 61801 Tel (217) 244 6568 Web http://www.cs.uiuc.edu/homes/snir

1 0

Re: [Mpi3-hybridpm] Clarification on single-communication multiple-threads in latest proposal (9-nov-2009)
by Douglas Miller 11 Nov '09

11 Nov '09

That's an interesting idea. How would a thread that attaches as a "helper" actually end up in the progress engine? Does the thread relinquish control when it attaches as a helper? Thus the MPI ADI would simply not return but rather call into a messaging layer progress loop? And then the "detach all helper threads" call would set some flag that causes the helper threads to break out of the loop and return? In this case, do you envision these helper threads are all attached to the same endpoint, or are there separate endpoints? "Snir, Marc" <snir(a)illinois.ed u> To Sent by: "mpi3-hybridpm(a)lists.mpi-forum.org" mpi3-hybridpm-bou <mpi3-hybridpm(a)lists.mpi-forum.org> nces(a)lists.mpi-fo cc rum.org Subject Re: [Mpi3-hybridpm] Clarification 11/11/2009 05:05 on single-communication AM multiple-threads in latest proposal (9-nov-2009) Please respond to mpi3-hybridpm@lis ts.mpi-forum.org Possible design with two new calls: 1 A thread can attach as helper; 2 an attached compute thread can detach all helper threads from it's endpoint. Short iphone email On Nov 11, 2009, at 12:19 AM, "Snir, Marc" <snir(a)illinois.edu> wrote: > I put a placeholder for this idea. It is easy for a thread to join as > a helper. Harder for the apllication to request the thread back > > Short iphone email > > > On Nov 10, 2009, at 3:03 PM, "Douglas Miller" <dougmill(a)us.ibm.com> > wrote: > >> >> I've been looking at the latest (v3) MPI3 Hybrid proposal and had a >> question about support for parallelism within a communication. It >> seems >> that the direction we're going here is to have the application own >> threads >> and then "lend" them to the messaging software for use during >> communications. This model works well in many situations, so it >> seems worth >> pursuing. One situation that it works well is when oversubscribing >> processor resources is detrimental to performance, and so the >> application >> and messaging layers should be cooperative about using threads and >> avoiding >> oversubscription. >> >> The dimension of parallelism in question is where multiple threads >> need to >> participate in a single communication, either point-to-point or >> collective. >> The way in which those threads will participate is up to the >> messaging >> software, but some examples are: message striping across multiple >> channels >> of a network (or shared memory) and collectives that consist of >> compound >> communications operations that benefit from multiple threads each >> performing a role in the larger collective. The question is, how >> would this >> be supported when using the model of threads, endpoints, and agents? >> >> Some examples might help illustrate the concerns. Consider a blocking >> collective that can benefit from parallelism. In order for the >> application >> to assign threads (or agents) to the collective, multiple threads >> must call >> into the messaging layer and indicate that they are part of the >> particular >> collective. This requires some sort of common identifier or other >> mechanism >> by which the messaging layer can identify these threads as being >> part of >> the same collective. Since the operation is blocking, there is no >> "request" >> or other object that can be used in a WAIT, so in order to ensure all >> threads are involved in the progress of the collective the >> application must >> arrange for each thread to call. Non-blocking calls also present >> problems, >> as there probably needs to be multiple requests generated which are >> shared >> among threads (agents) which all make progress individually. >> >> There are likely other ways to solve this, but the idea is to expose >> this >> dimension of parallelism such that applications can be written to >> take >> advantage of it. It would always be the case that a message layer >> could >> choose to use only one participant, the rest essentially performing >> a NO-OP >> (or barrier). It would also always be valid for an application to >> use only >> one thread, and not take advantage of possible parallelism. >> >> thanks, >> >> _______________________________________________ >> Douglas Miller BlueGene Messaging Development >> IBM Corp., Rochester, MN USA Bldg 030-2 A410 >> dougmill(a)us.ibm.com Douglas Miller/Rochester/IBM >> >> _______________________________________________ >> Mpi3-hybridpm mailing list >> Mpi3-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm > > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm _______________________________________________ Mpi3-hybridpm mailing list Mpi3-hybridpm(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm

1 0