[Mpi3-hybridpm] Regarding making changes to Open-MP to eliminate need for MPI_HELPER_TEAM
Douglas Miller
dougmill at us.ibm.com
Wed Feb 16 11:51:13 CST 2011
OK, I think that is a lot easier to respond to. I have re-phrased my
question to the compiler folks and will compose some text to explain why
that idea won't work, or at least defeats the purpose.
_______________________________________________
Douglas Miller BlueGene Messaging Development
IBM Corp., Rochester, MN USA Bldg 030-2 A410
dougmill at us.ibm.com Douglas Miller/Rochester/IBM
"Bronis R. de
Supinski"
<bronis at llnl.gov> To
Sent by: "mpi3-hybridpm at lists.mpi-forum.org"
mpi3-hybridpm-bou <mpi3-hybridpm at lists.mpi-forum.org>
nces at lists.mpi-fo cc
rum.org
Subject
Re: [Mpi3-hybridpm] Regarding
02/16/2011 11:45 making changes to Open-MP to
AM eliminate need for MPI_HELPER_TEAM
Please respond to
"Bronis R. de
Supinski"
<bronis at llnl.gov>
; Please respond
to
mpi3-hybridpm at lis
ts.mpi-forum.org
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
>
>
_______________________________________________
Mpi3-hybridpm mailing list
Mpi3-hybridpm at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20110216/2c2f884b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20110216/2c2f884b/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic12558.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20110216/2c2f884b/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20110216/2c2f884b/attachment-0005.gif>
More information about the mpiwg-hybridpm
mailing list