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 [email protected] Douglas Miller/Rochester/IBM "Bronis R. de Supinski" <[email protected]> To Sent by: "[email protected]" mpi3-hybridpm-bou <[email protected]> [email protected] cc rum.org Subject Re: [Mpi3-hybridpm] Regarding 02/16/2011 11:26 making changes to Open-MP to AM eliminate need for MPI_HELPER_TEAM Please respond to "Bronis R. de Supinski" <[email protected]> ; Please respond to mpi3-hybridpm@lis ts.mpi-forum.org 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 [email protected] Douglas Miller/Rochester/IBM

_______________________________________________ Mpi3-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm