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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
