On Jul 31, 2016, at 5:28 PM, George Bosilca <bosi...@icl.utk.edu
<mailto:bosi...@icl.utk.edu>> wrote:
Bradley,
We had similar needs in one of our projects and as a quick hack we
extended the GRequest interface to support persistent requests. There
are cleaner ways, but we decided that highjacking
the OMPI_REQUEST_GEN was good enough for a proof-of-concept. Then add
a start member to the ompi_grequest_t in request/grequest.h, and then
do what Nathan suggested by extending the switch in the
ompi/mpi/c/start.c (and startall), and directly call your own start
function.
George.
On Sat, Jul 30, 2016 at 6:29 PM, Jeff Squyres (jsquyres)
<jsquy...@cisco.com <mailto:jsquy...@cisco.com>> wrote:
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
<mailto: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
<mailto: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
<mailto: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
<mailto: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 <mailto:devel@lists.open-mpi.org>
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel@lists.open-mpi.org <mailto:devel@lists.open-mpi.org>
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel@lists.open-mpi.org <mailto:devel@lists.open-mpi.org>
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
--
Jeff Squyres
jsquy...@cisco.com <mailto: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 <mailto:devel@lists.open-mpi.org>
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@lists.open-mpi.org <mailto:devel@lists.open-mpi.org>
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
