[Mpi3-hybridpm] endpoint proposal

[Supalov, Alexander]

Well, I did explain this. But since you've considered this matter already, and they will be merged in one chapter anyway, that's fine.

-----Original Message-----
From: Pavan Balaji [mailto:balaji at mcs.anl.gov] 
Sent: Tuesday, October 25, 2011 12:27 AM
To: Supalov, Alexander
Cc: mpi3-hybridpm at lists.mpi-forum.org
Subject: Re: [Mpi3-hybridpm] endpoint proposal

Alexander,

We have discussed these two proposals and how they interact with each 
other several times in the working group. We don't believe any changes 
are required in either proposal for them to work together. Also, either 
proposal would work without the other proposal. So they are, in fact, 
orthogonal.

With respect to merging the two proposals, there is no good reason to. 
You did not explain why one proposal depends on the other. If there is 
no dependency, merging is not required.

  -- Pavan

On 10/24/2011 04:53 PM, Supalov, Alexander wrote:
> Thanks. I don't think they are orthogonal.
>
> They are mutually exclusive as far as the resulting thread states are concerned. You may have:
>
> 0 (thread has no MPI involvement at all)
> A (thread is used as a helper thread by the MPI implementation)
> B (thread is used MPI by the MPI user in association w/ some endpoint)
>
> And there's no AB (both helper and user thread w/ MPI). So, B above is actually -A.
>
> Thus, the proposals will have to deal with the transitions 0A, A0, 0(-A),-A0, and most interestingly, -AA and A(-A).
>
> Basing on this, it may be necessary to consider them together and make reciprocal adjustments in both documents.
>
> The means of achieving the states A and -A may indeed appear orthogonal at the moment. I'd argue the closer they look, the better off we'll be. The helper thread proposal looks very rich on the ways to cut the cake. The endpoint proposal looks rather minimalistic. Would the helper thread proposal profit from some simplification? After all, you're "only" giving a thread on loan to the MPI. This should be doable with 1 call, maximum 2 (in and out).
>
> I can even imagine that the THREAD_JOIN might look like (join user MPI space w/ assoc. endpoint) and (join MPI implementation space). Then the means would not be orthogonal either, reflecting the mutual exclusivity of the resp. states. This would arguably be a better design.
>
> If the above makes sense, we'd rather merge the proposals.
>
> -----Original Message-----
> From: Pavan Balaji [mailto:balaji at mcs.anl.gov]
> Sent: Monday, October 24, 2011 5:03 PM
> To: mpi3-hybridpm at lists.mpi-forum.org
> Cc: Supalov, Alexander
> Subject: Re: [Mpi3-hybridpm] endpoint proposal
>
> Alexander,
>
> These are orthogonal concepts. Users can certainly use them together,
> but there is no reason to merge them.
>
>    -- Pavan
>
> On 10/24/2011 05:25 AM, Supalov, Alexander wrote:
>> Thanks. Has someone tried to look into #217 (helper threads) and #284 (endpoints) with the view on merging them? After all, threads attaching to the endpoints are almost, but not quite unlike helper threads given on "loan" to the MPI implementation. In the first case, the application is using the threads by itself. In the second case, the MPI is using threads for internal purposes. See the analogy? In both cases we let threads use or be used by MPI. Is this something one could possibly unite? They are being placed like on different sides of the boundary:
>>
>> Endpoints (#284):
>>
>> 	Application threads
>> 	Endpoints
>> 	Communication resources
>>
>> Helper threads (#217):
>>
>> 	[Endpoints]
>> 	Internal threads
>> 	Communication resources
>>
>> So, if we merge the pictures:
>>
>> 	Application threads
>> 	Endpoints (#284)
>> 	Internal threads (#217)
>> 	Communication resources
>>
>> And what the unification would do is provide a way to convert the application threads into the internal threads and back. May be orthogonal, but certainly deserves a joint consideration.
>>
>> -----Original Message-----
>> From: mpi3-hybridpm-bounces at lists.mpi-forum.org [mailto:mpi3-hybridpm-bounces at lists.mpi-forum.org] On Behalf Of Marc Snir
>> Sent: Thursday, October 20, 2011 10:40 PM
>> To: mpi3-hybridpm at lists.mpi-forum.org
>> Subject: [Mpi3-hybridpm] endpoint proposal
>>
>> Slides and text for the endpoint proposal
>>
>>
>>
>> --------------------------------------------------------------------------------------
>> Intel GmbH
>> Dornacher Strasse 1
>> 85622 Feldkirchen/Muenchen, Deutschland
>> Sitz der Gesellschaft: Feldkirchen bei Muenchen
>> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
>> Registergericht: Muenchen HRB 47456
>> Ust.-IdNr./VAT Registration No.: DE129385895
>> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
>>
>>
>> _______________________________________________
>> Mpi3-hybridpm mailing list
>> Mpi3-hybridpm at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm
>

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji
--------------------------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland 
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052