[Mpi3-hybridpm] Regarding making changes to Open-MP to eliminate need for MPI_HELPER_TEAM
Bronis R. de Supinski
bronis at llnl.gov
Wed Feb 16 11:45:48 CST 2011
Yes, as if by magic.
On Wed, 16 Feb 2011, Douglas Miller wrote:
> Oh, that's different than what I was thinking. I thought there was some extension to Open-MP being proposed.
>
> OK, so the suggestion was that MPI could just do a "#pragma omp parallel" (or equivalent) internally? And if the omp runtime/compiler was "smart" enough it would work well?
>
>
> _______________________________________________
> Douglas Miller BlueGene Messaging Development
> IBM Corp., Rochester, MN USA Bldg 030-2 A410
> dougmill at us.ibm.com Douglas Miller/Rochester/IBM
>
> [cid:1__=09BBF2AADFF3FC168f9e8a93df938 at us.ibm.com]"Bronis R. de Supinski" ---02/16/2011 11:28:04 AM---Doug:
>
>
> "Bronis R. de Supinski" <bronis at llnl.gov>
> Sent by: mpi3-hybridpm-bounces at lists.mpi-forum.org
>
> 02/16/2011 11:26 AM
> Please respond to
> "Bronis R. de Supinski" <bronis at llnl.gov>; Please respond to
> mpi3-hybridpm at lists.mpi-forum.org
>
>
>
>
> To
>
>
> "mpi3-hybridpm at lists.mpi-forum.org" <mpi3-hybridpm at lists.mpi-forum.org>
>
>
>
> cc
>
>
>
> Subject
>
>
> Re: [Mpi3-hybridpm] Regarding making changes to Open-MP to eliminate need for MPI_HELPER_TEAM
>
>
>
>
>
>
> Doug:
>
> The suggested was that nested parallelism would magically
> result in the MPI thread being able to generate more threads.
>
> Bronis
>
>
> On Wed, 16 Feb 2011, Douglas Miller wrote:
>
>> I'm am still discussing this with compiler folks here at IBM, but I was reminded of a point that I think makes the question moot.
>>
>> Even if open-mp allows the user to get control of threads (or tasks) when they go idle, it doesn't solve the problem which is how does a task that (otherwise) makes no MPI calls get involved in other thread's MPI calls? There is currently no interface into MPI that provides a general-purpose "I want to help others" action. At the very least we'd have to modify the interface or semantics to MPI_WAIT/MPI_TEST to allow for calling without a request (essentially creating MPI_HELPER_TEAM_YIELD).
>>
>> Unless the idea was that MPI itself somehow registered itself with the open-mp runtime such that the application had no idea. Then I suppose the MPI implementation could provide some internal (MPID) function that did what was necessary. But that raises all sorts of questions for things like applications that use both MPI and UPC, who wins the registration - MPI or UPC? Not to mention that if this were a public open-mp feature what's to stop the application from also wanting to register a function? A lot depends on exactly how this were implemented and exposed.
>>
>> and then there's the issue of applications that do threading some other way - pthreads, fork, whatever - does every potential threading runtime have to be modified? or how does the user accomplish this same thing without Open-MP? It just seems more universally-useful if MPI does this, rather than every threading platform in the world. Of course, things like UPC and GA/ARMCI also need to provide similar features. It just seems more problematic trying to get OSes and Compilers to add this.
>>
>> I think I'm rambling-on too much. Maybe no one needs to respond to this - it is just input for our next discussion.
>>
>> Anyway, I'm still exchanging e-mail with compiler folks on this. Right now, they are having a hard time understanding what I'm asking for. I guess the idea is so vague that I can't even give them sample code or a hypothetical interface.
>>
>>
>> _______________________________________________
>> Douglas Miller BlueGene Messaging Development
>> IBM Corp., Rochester, MN USA Bldg 030-2 A410
>> 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
>
>
More information about the mpiwg-hybridpm
mailing list