[mpich-devel] call PMI before MPI_Init_thread?

Jeff Hammond jeff.science at gmail.com
Sat Apr 25 19:16:22 CDT 2015


Sorry, I meant "change the PMI spec" instead of "implement", but I
guess it doesn't matter if it works everywhere.

Jeff

On Sat, Apr 25, 2015 at 4:23 PM, Balaji, Pavan <balaji at anl.gov> wrote:
>
> It works in the implementation, so I’m not sure what you mean.  I just mean it’s not allowed per the “spec” (or whatever sparse documentation we have that others use for implementing PMI).
>
>   — Pavan
>
>> On Apr 24, 2015, at 7:22 AM, Jeff Hammond <jeff.science at gmail.com> wrote:
>>
>> Why not implement the equivalent of the ref-counting init proposal or
>> at least the simple things that allows multiple inits but only one
>> finalize?  Is it that you don't see the effort being worthwhile or
>> because there is a principled reason (PMI semantics should match MPI)?
>>
>> Given that e.g. PGAS runtimes may want to use PMI for bootstrapping (I
>> do this with DMAPP code on Cray, for example), it seems to benefit
>> user experience to support this behavior.
>>
>> Thanks,
>>
>> Jeff
>>
>> On Fri, Apr 24, 2015 at 1:12 AM, Balaji, Pavan <balaji at anl.gov> wrote:
>>>
>>> Multiple PMI Inits are not allowed.  It might work in the current
>>> implementation within MPICH, but is not safe.
>>>
>>> If you are looking for MPICH specific behavior, you can look for the PMI_ID
>>> and PMI_RANK environment variables instead to get your rank.
>>>
>>>  — Pavan
>>>
>>> On Apr 21, 2015, at 11:17 PM, Jeff Hammond <jeff.science at gmail.com> wrote:
>>>
>>> So MPICH doesn't fail when I try this on my Mac, but it would be good
>>> to know if I have a reasonable expectation of doing this in general.
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>> jrhammon-mac01:ENDPOINTS jrhammon$ mpiexec -n 4 ./a.out
>>> PMI says I am 2 of 4
>>> PMI says I am 0 of 4
>>> PMI says I am 1 of 4
>>> PMI says I am 3 of 4
>>> MPI says I am 0 of 4 (provided=1)
>>> MPI says I am 2 of 4 (provided=1)
>>> MPI says I am 3 of 4 (provided=3)
>>> MPI says I am 1 of 4 (provided=3)
>>>
>>> jrhammon-mac01:ENDPOINTS jrhammon$ cat pmi.c
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> /*#include <pmi.h>*/
>>> int PMI_Init( int *spawned );
>>> int PMI_Finalize( void );
>>> int PMI_Get_size( int *size );
>>> int PMI_Get_rank( int *rank );
>>>
>>> #include <mpi.h>
>>>
>>> int main(int argc, char * argv[])
>>> {
>>>   int has_parent;
>>>   PMI_Init(&has_parent);
>>>
>>>   int rank, size;
>>>   PMI_Get_size(&size);
>>>   PMI_Get_rank(&rank);
>>>
>>>   printf("PMI says I am %d of %d \n", rank, size);
>>>   fflush(stdout);
>>>
>>>   int requested = (rank%2==0) ? MPI_THREAD_FUNNELED : MPI_THREAD_MULTIPLE;
>>>   int provided;
>>>   MPI_Init_thread(&argc, &argv, requested, &provided);
>>>
>>>   int wsize, wrank;
>>>   MPI_Comm_size(MPI_COMM_WORLD, &wsize);
>>>   MPI_Comm_rank(MPI_COMM_WORLD, &wrank);
>>>
>>>   printf("MPI says I am %d of %d (provided=%d)\n", wrank, wsize, provided);
>>>   fflush(stdout);
>>>
>>>   MPI_Finalize();
>>>   //PMI_Finalize(); /* required? */
>>>
>>>   return 0;
>>> }
>>>
>>> On Tue, Apr 21, 2015 at 9:09 PM, Jeff Hammond <jeff.science at gmail.com>
>>> wrote:
>>>
>>> Is it valid in _MPICH_ to make calls to PMI before MPI is initialized?
>>> I am interested in PMI_Init, PMI_Get_size and PMI_Get_rank.
>>>
>>> The motivating use case is to initialize e.g. half my ranks with
>>> MPI_THREAD_FUNNELED and the other half with MPI_THREAD_MULTIPLE but
>>> not use MPMD launching.
>>>
>>> I have two reasons for wanting to do it this way.  First, it is
>>> otherwise unnecessary to use MPMD since I can branch at the top of my
>>> code and meet the requirements of FUNNELED and MULTIPLE.  Second, I
>>> might be interested in running my code on a supercomputer with an
>>> MPICH-based MPI implementation that does not support MPMD launching in
>>> an unrestricted manner.
>>>
>>> If MPICH can handle this, then I will worry about whether or not the
>>> aforementioned supercomputer can.  It is my assumption that, if MPICH
>>> cannot handle this, then the MPICH derivative in question cannot
>>> either.
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>> --
>>> Jeff Hammond
>>> jeff.science at gmail.com
>>> http://jeffhammond.github.io/
>>>
>>>
>>>
>>>
>>> --
>>> Jeff Hammond
>>> jeff.science at gmail.com
>>> http://jeffhammond.github.io/
>>> _______________________________________________
>>> To manage subscription options or unsubscribe:
>>> https://lists.mpich.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> _______________________________________________
>>> To manage subscription options or unsubscribe:
>>> https://lists.mpich.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Jeff Hammond
>> jeff.science at gmail.com
>> http://jeffhammond.github.io/
>> _______________________________________________
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/devel
>
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/


More information about the devel mailing list