[OMPI devel] Commit emails: not working

[Jeff Squyres (jsquyres)]

FYI: It looks like the normal emails we get upon commits are not being 
delivered.

Working on it.

-- 
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

[OMPI devel] MCA Component Development: Function Pointers

[Bradley Morgan]

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

Re: [OMPI devel] MCA Component Development: Function Pointers

[Gilles Gouaillardet]

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  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

Re: [OMPI devel] MCA Component Development: Function Pointers

[Bradley Morgan]

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 
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 
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
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

Re: [OMPI devel] MCA Component Development: Function Pointers

[Nathan Hjelm]

Look at ompi/mpi/c/start.c. Just add a check there thst redirects to the coll 
component for coll requests. You will probably need to expand the coll 
interface in ompi/mca/coll/coll.h to include a start function.

> On Jul 29, 2016, at 10:20 AM, Bradley Morgan  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 
>>  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  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
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Performance analysis proposal

[Arm Patinyasakdikul (apatinya)]

Hey Artem, all,

Thank you for the benchmark prototype. I have created the discussion page here 
: https://github.com/open-mpi/2016-summer-perf-testing/issues/1.

  *   There, I have single threaded and multithreaded performance posted.
  *   The script I used is now in the repo (also in the discussion page)
  *   Result with openib will come up probably next week. I have to access UTK 
machine for that.
  *   I did some test and yes, I have seen some openib hang in multithreaded 
case.

Thank you,
Arm


From: devel 
mailto:devel-boun...@lists.open-mpi.org>> on 
behalf of Artem Polyakov mailto:artpo...@gmail.com>>
Reply-To: Open MPI Developers 
mailto:devel@lists.open-mpi.org>>
Date: Thursday, July 28, 2016 at 10:42 PM
To: Open MPI Developers 
mailto:devel@lists.open-mpi.org>>
Subject: Re: [OMPI devel] Performance analysis proposal

Thank you, Arm!

Good to have vader results (I haven't tried it myself yet). Few 
comments/questions:
1. I guess we also want to have 1-threaded performance for the "baseline" 
reference.
2. Have you tried to run with openib, as I mentioned on the call I had some 
problems with it and I'm curious if you can reproduce in your environment.

Github issue sounds good for me!

2016-07-29 12:30 GMT+07:00 Arm Patinyasakdikul (apatinya) 
mailto:apati...@cisco.com>>:
I added some result to https://github.com/open-mpi/2016-summer-perf-testing

The result shows much better performance from 2.0.0 and master over 1.10.3 for 
vader. The test ran with Artem’s version of benchmark on OB1, single node, bind 
to socket.

We should have a place to discuss/comment/collaborate on results. Should I open 
an issue on that repo? So we can have github style commenting/referencing.


Arm




On 7/28/16, 3:02 PM, "devel on behalf of Jeff Squyres (jsquyres)" 
mailto:devel-boun...@lists.open-mpi.org> on 
behalf of jsquy...@cisco.com> wrote:

>On Jul 28, 2016, at 6:28 AM, Artem Polyakov 
>mailto:artpo...@gmail.com>> wrote:
>>
>> Jeff and others,
>>
>> 1. The benchmark was updated to support shared memory case.
>> 2. The wiki was updated with the benchmark description: 
>> https://github.com/open-mpi/ompi/wiki/Request-refactoring-test#benchmark-prototype
>
>Sweet -- thanks!
>
>> Let me know if we want to put this prototype to some general place. I think 
>> it makes sense.
>
>I just created:
>
>https://github.com/open-mpi/2016-summer-perf-testing
>
>Want to put it there?
>
>Arm just ran a bunch of tests today and will be committing a bunch of results 
>in there shortly.
>
>--
>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
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel



--
С Уважением, Поляков Артем Юрьевич
Best regards, Artem Y. Polyakov
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] MCA Component Development: Function Pointers

[Gilles Gouaillardet]

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  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  > 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