Re: [OMPI devel] New frameworks and contribs in the trunk

2009-08-24 Thread George Bosilca 


On Aug 21, 2009, at 07:33 , Ralph Castain wrote:


Hi Rich

On Aug 21, 2009, at 5:14 AM, Graham, Richard L. wrote:

I have several questions here - since process migration is an open  
research question,

and there is more than one way to address the issue -
- Is this being implemented as a component, so that other  
approaches can be used ?


Absolutely - we have several organizations involved, all with  
competing approaches


This become a recurrent statement, every time something smelly should  
be defended.



- If so, what sort of component interface is being considered ?


Still being determined. One reason for exposing the frameworks at  
this time is that much of the ongoing effort may occur in separate,  
hidden tmp branches for proprietary reasons. The eventual source  
code for those components may well never be committed, but the  
frameworks need to be in the system so that MCA will pickup the  
binary modules.


This is a wrong reason. We did multi-institution work in the past  
starting from a tmp branch. The only overhead is that somebody has to  
keep the copy in sync with the trunk, but this approach at least has  
the merit to keep our trunk [more or less] clean.


I deliberately left the frameworks "inactive" so that changes in the  
APIs can be done as the work progresses without impacting the OMPI  
community. The participants need to develop a little further before  
we fully understand what the APIs need to be - a little hard to  
openly discuss them without exposing potentially proprietary algos.  
The hope is that, as people develop their components, they can  
identify missing needs in the API so at least that much can be  
safely communicated and resolved.



- What is the impact (or expected impact) on the rest of the system ?


For anyone who doesn't explicitly build it and turn it on, nothing.  
For those who do, there will be no impact on MPI procs themselves as  
they won't load nor activate these frameworks. There will be an  
increased orted footprint and activity level, which could  
potentially reduce performance by stealing cycles from MPI procs -  
obviously, that depends on #procs vs cores and other factors.


If nobody knows how to do it, this _clearly_ should be a good enough  
reason to do the work in a temp branch before polluting the trunk.


  george.




I'm speaking solely of the RTE impact and issues here, of course -  
Josh would have to address the MPI perspective.


HTH
Ralph



Thanks,
Rich


On 8/20/09 6:57 PM, "Ralph Castain"  wrote:

Hmmm...I'm afraid I cannot entirely substantiate your concerns.
Everything compiles just fine for me under both Linux and OSX. True,
the files are not completely instantiated on the trunk at this time,
but they also are not activated on the trunk for precisely that  
reason.


Can you provide an example of where something isn't building? I can't
find it on any platform available to me.

Thanks
Ralph

On Aug 20, 2009, at 4:32 PM, George Bosilca wrote:


Ralph,

I'm a little bit concerned about the commits stated below as their
quality doesn't match the usual quality standards of the trunk.
There are several issues: mostly empty files, names coming from
other frameworks, failure to compile on several platforms (including
Linux and MAC OS X). I'm more than happy to see research code in the
trunk, and I will be really interested to see the proof that
preemptive migration works. However, the quality of the trunk should
not suffer.

Moreover, we have mercurial and svn temporary repositories for such
kind of work. And we did force people in the past to work on
temporary branches before such large commits on the trunk.

Please reconsider your patches.

Thanks,
 george.



https://svn.open-mpi.org/trac/ompi/changeset/21849
https://svn.open-mpi.org/trac/ompi/changeset/21850
https://svn.open-mpi.org/trac/ompi/changeset/21848
https://svn.open-mpi.org/trac/ompi/changeset/21847

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] New frameworks and contribs in the trunk

2009-08-21 Thread Ralph Castain 

Hi Rich

On Aug 21, 2009, at 5:14 AM, Graham, Richard L. wrote:

I have several questions here - since process migration is an open  
research question,

and there is more than one way to address the issue -
- Is this being implemented as a component, so that other approaches  
can be used ?


Absolutely - we have several organizations involved, all with  
competing approaches



- If so, what sort of component interface is being considered ?


Still being determined. One reason for exposing the frameworks at this  
time is that much of the ongoing effort may occur in separate, hidden  
tmp branches for proprietary reasons. The eventual source code for  
those components may well never be committed, but the frameworks need  
to be in the system so that MCA will pickup the binary modules.


I deliberately left the frameworks "inactive" so that changes in the  
APIs can be done as the work progresses without impacting the OMPI  
community. The participants need to develop a little further before we  
fully understand what the APIs need to be - a little hard to openly  
discuss them without exposing potentially proprietary algos. The hope  
is that, as people develop their components, they can identify missing  
needs in the API so at least that much can be safely communicated and  
resolved.




- What is the impact (or expected impact) on the rest of the system ?


For anyone who doesn't explicitly build it and turn it on, nothing.  
For those who do, there will be no impact on MPI procs themselves as  
they won't load nor activate these frameworks. There will be an  
increased orted footprint and activity level, which could potentially  
reduce performance by stealing cycles from MPI procs - obviously, that  
depends on #procs vs cores and other factors.



I'm speaking solely of the RTE impact and issues here, of course -  
Josh would have to address the MPI perspective.


HTH
Ralph



Thanks,
Rich


On 8/20/09 6:57 PM, "Ralph Castain"  wrote:

Hmmm...I'm afraid I cannot entirely substantiate your concerns.
Everything compiles just fine for me under both Linux and OSX. True,
the files are not completely instantiated on the trunk at this time,
but they also are not activated on the trunk for precisely that  
reason.


Can you provide an example of where something isn't building? I can't
find it on any platform available to me.

Thanks
Ralph

On Aug 20, 2009, at 4:32 PM, George Bosilca wrote:


Ralph,

I'm a little bit concerned about the commits stated below as their
quality doesn't match the usual quality standards of the trunk.
There are several issues: mostly empty files, names coming from
other frameworks, failure to compile on several platforms (including
Linux and MAC OS X). I'm more than happy to see research code in the
trunk, and I will be really interested to see the proof that
preemptive migration works. However, the quality of the trunk should
not suffer.

Moreover, we have mercurial and svn temporary repositories for such
kind of work. And we did force people in the past to work on
temporary branches before such large commits on the trunk.

Please reconsider your patches.

Thanks,
  george.



https://svn.open-mpi.org/trac/ompi/changeset/21849
https://svn.open-mpi.org/trac/ompi/changeset/21850
https://svn.open-mpi.org/trac/ompi/changeset/21848
https://svn.open-mpi.org/trac/ompi/changeset/21847

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] New frameworks and contribs in the trunk

2009-08-21 Thread Graham, Richard L. 
I have several questions here - since process migration is an open research 
question,
 and there is more than one way to address the issue -
 - Is this being implemented as a component, so that other approaches can be 
used ?
 - If so, what sort of component interface is being considered ?
 - What is the impact (or expected impact) on the rest of the system ?

Thanks,
Rich


On 8/20/09 6:57 PM, "Ralph Castain"  wrote:

Hmmm...I'm afraid I cannot entirely substantiate your concerns.
Everything compiles just fine for me under both Linux and OSX. True,
the files are not completely instantiated on the trunk at this time,
but they also are not activated on the trunk for precisely that reason.

Can you provide an example of where something isn't building? I can't
find it on any platform available to me.

Thanks
Ralph

On Aug 20, 2009, at 4:32 PM, George Bosilca wrote:

> Ralph,
>
> I'm a little bit concerned about the commits stated below as their
> quality doesn't match the usual quality standards of the trunk.
> There are several issues: mostly empty files, names coming from
> other frameworks, failure to compile on several platforms (including
> Linux and MAC OS X). I'm more than happy to see research code in the
> trunk, and I will be really interested to see the proof that
> preemptive migration works. However, the quality of the trunk should
> not suffer.
>
> Moreover, we have mercurial and svn temporary repositories for such
> kind of work. And we did force people in the past to work on
> temporary branches before such large commits on the trunk.
>
> Please reconsider your patches.
>
>  Thanks,
>george.
>
>
>
> https://svn.open-mpi.org/trac/ompi/changeset/21849
> https://svn.open-mpi.org/trac/ompi/changeset/21850
> https://svn.open-mpi.org/trac/ompi/changeset/21848
> https://svn.open-mpi.org/trac/ompi/changeset/21847
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] New frameworks and contribs in the trunk

2009-08-20 Thread Ralph Castain 
Hmmm...I'm afraid I cannot entirely substantiate your concerns.  
Everything compiles just fine for me under both Linux and OSX. True,  
the files are not completely instantiated on the trunk at this time,  
but they also are not activated on the trunk for precisely that reason.


Can you provide an example of where something isn't building? I can't  
find it on any platform available to me.


Thanks
Ralph

On Aug 20, 2009, at 4:32 PM, George Bosilca wrote:


Ralph,

I'm a little bit concerned about the commits stated below as their  
quality doesn't match the usual quality standards of the trunk.  
There are several issues: mostly empty files, names coming from  
other frameworks, failure to compile on several platforms (including  
Linux and MAC OS X). I'm more than happy to see research code in the  
trunk, and I will be really interested to see the proof that  
preemptive migration works. However, the quality of the trunk should  
not suffer.


Moreover, we have mercurial and svn temporary repositories for such  
kind of work. And we did force people in the past to work on  
temporary branches before such large commits on the trunk.


Please reconsider your patches.

 Thanks,
   george.



https://svn.open-mpi.org/trac/ompi/changeset/21849
https://svn.open-mpi.org/trac/ompi/changeset/21850
https://svn.open-mpi.org/trac/ompi/changeset/21848
https://svn.open-mpi.org/trac/ompi/changeset/21847

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] New frameworks and contribs in the trunk

2009-08-20 Thread George Bosilca 

Ralph,

I'm a little bit concerned about the commits stated below as their  
quality doesn't match the usual quality standards of the trunk. There  
are several issues: mostly empty files, names coming from other  
frameworks, failure to compile on several platforms (including Linux  
and MAC OS X). I'm more than happy to see research code in the trunk,  
and I will be really interested to see the proof that preemptive  
migration works. However, the quality of the trunk should not suffer.


Moreover, we have mercurial and svn temporary repositories for such  
kind of work. And we did force people in the past to work on temporary  
branches before such large commits on the trunk.


Please reconsider your patches.

  Thanks,
george.



https://svn.open-mpi.org/trac/ompi/changeset/21849
https://svn.open-mpi.org/trac/ompi/changeset/21850
https://svn.open-mpi.org/trac/ompi/changeset/21848
https://svn.open-mpi.org/trac/ompi/changeset/21847