Also be aware of the Open MPI Extensions framework, explicitly intended for
adding new/experimental APIs to mpi.h and the Fortran equivalents. See
ompi/mpiext.
> On Jul 29, 2016, at 11:16 PM, Gilles Gouaillardet
> <gilles.gouaillar...@gmail.com> wrote:
>
> For a proof-of-concept, I'd rather suggest you add MPI_Pcoll_start(), and add
> a pointer in mca_coll_base_comm_coll_t.
> If you add MCA_PML_REQUEST_COLL, then you have to update all pml components
> (fastidious), if you update start.c (quite simple), then you also need to
> update start_all.c (less trivial)
> If the future standard mandates the use of MPI_Start and MPI_Startall, then
> we will reconsider this.
>
> From a performance point of view, that should not change much.
> IMHO, non blocking collectives come with a lot of overhead, so shaving a few
> nanoseconds here and then will unlikely change the big picture.
>
> If I oversimplify libnbc, it basically schedule MPI_Isend, MPI_Irecv and
> MPI_Wait (well, MPI_Test since this is on blocking, but let's keep it simple)
> My intuition is your libpnbc will post MPI_Send_init, MPI_Recv_init, and
> schedule MPI_Start and MPI_Wait.
> Because of the overhead, I would only expect marginal performance
> improvement, if any.
>
> Cheers,
>
> Gilles
>
> On Saturday, July 30, 2016, Bradley Morgan <morg...@auburn.edu> wrote:
>
> Hello Gilles,
>
> Thank you very much for your response.
>
> My understanding is yes, this might be part of the future standard—but
> probably not from my work alone. I’m currently just trying get a
> proof-of-concept and some performance metrics.
>
> I have item one of your list completed, but not the others. I will look into
> adding the MCA_PML_REQUEST_COLL case to mea_pml_ob1_start.
>
> Would it also be feasible to create a new function and pointer in
> mca_coll_base_comm_coll_t struct, (i.e. mca_coll_base_module_istart, etc.)
> just to get a proof of concept? Do you think this would be a fairly accurate
> representation (in regard to performance, not necessarily semantics) of how
> the standard\official implementation would work?
>
>
> Once again, thanks very much for this information!
>
>
> Regards,
>
> -Bradley
>
>
>
>> On Jul 29, 2016, at 10:54 AM, Gilles Gouaillardet
>> <gilles.gouaillar...@gmail.com> wrote:
>>
>> Out of curiosity, is MPI_Ibcast_init (and friends) something that will/might
>> be part of the future standard ?
>>
>> if you want to implement this as a MCA, then you have (at least) to
>> - add an Ibcast_init field (function pointer) to mca_coll_base_comm_coll_t
>> struct
>> - add a 'case MCA_PML_REQUEST_COLL:' in mca_pml_ob1_start
>> - ensure these request are progressed
>> - ensure these requests can be MPI_{Wait,Test,Probe!Request_free!Cancel }
>> and friends
>>
>> note all coll components must initialize the new ibcast_init field to NULL
>> and all pml components should handle MCA_PML_REQUEST_COLL.
>>
>>
>> Cheers,
>>
>> Gilles
>>
>>
>> On Saturday, July 30, 2016, Bradley Morgan <morg...@auburn.edu> wrote:
>> Hello OpenMPI Developers,
>>
>> (I am new to the community, so please forgive me if I violate any protocols
>> or seem naive here…)
>>
>>
>> I am currently working on a prototype component for persistent nonblocking
>> collectives (ompi->mca->coll->libpnbc).
>>
>> I have integrated my new component and mapped MPI_IBcast to my own _init
>> function, which initiates a request but does not start it. Next, I would
>> like to create a function pointer for MPI_Start to kick off these requests.
>> However, the pointer(s) for MPI_Start live in the pml (point-to-point)
>> framework and its implementation seems tacit to MCA. I was able to trace
>> the default mapping of MPI_Start for my build to
>> pml->ob1->pml_ob1_start.c->mca_pml_ob1_start(), but I can’t seem to
>> translate the magic in that path to my own component.
>>
>> Alternatively, if trying to map MPI_Start is too difficult, I think I could
>> also create a custom function like LIBPNBC_Start just to get past this and
>> begin testing, but I have not yet found a clean way to make a custom
>> component function visible and useable at the MPI level.
>>
>>
>> If anyone has any advice or can direct me to any applicable resources
>> (mostly regarding function mapping \ publishing for MPI components) it would
>> be greatly appreciated!
>>
>>
>> Thanks very much!
>>
>>
>> -Bradley
>> _______________________________________________
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
