Ralph,
If you are suggesting that you will make code that breaks a current
rankfile feature, note I am not talking about adding a new feature that
isn't supported by rankfile but something that used to work, then I
think you are acting in poor form. At a minimum you should at least
give the community a heads up that you are borking a feature.
There are a lot of pieces of code that everyone changes that require
other changes that one is not completely responsible for. If everyone
decided it wasn't necessary to maintain/support those pieces our code
will soon be useless (maybe it is).
--td
Ralph Castain wrote:
Read the other "no" votes, and I can understand the points made. I noted that
neither respondent offered to maintain this feature, but indicated that it had some value.
There really isn't any need to make a decision about this because it will take care of
itself. Since no-one is maintaining it (and I really don't have time to continue to do
so), and it tends to break easily, this module will "self-deprecate" rather
soon. When that happens, we can wait and see if anyone cares enough to step forward and
take responsibility for maintaining it.
If not, then we can note that support for this feature went the way of other
things that died due to lack of interest within the developer community (e.g.,
xgrid)...which is totally okay since this is, after all, an open source effort.
On Apr 15, 2010, at 4:00 PM, Jeff Squyres wrote:
WHAT: Deprecate the "rankfile" component in the v1.5 series; remove it in the
1.7 series
WHY: It's old, creaky, and difficult to maintain. It'll require maintenance
someday soon, when we support hardware / hyperthreads in OMPI.
WHERE: svn rm orte/mca/rmaps/rank_file
WHEN: Deprecate in 1.5, remove in 1.7.
TIMEOUT: Teleconf on Tue, 27 April 2010
-----
Now that we have nice paffinity binding options, can we deprecate rankfile in
the 1.5 series and remove it in 1.7?
I only ask because it's kind of a pain to maintain. It's not a huge deal, but
Ralph and I were talking about another paffinity issue today and we both
groaned at the prospect of extending rank file to support hyperthreads (and/or
boards). Perhaps it should just go away...?
Pro: less maintenance, especially since the original developers no longer
maintain it
Con: it's the only way to have completely custom affinity bindings (i.e., outside of our
pre-constructed "bind to socket", "bind to core", etc. options). ...do any
other MPI's offer completely custom binding options? I.e., do any real users care?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
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
--
Oracle
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.650.633.7054
Oracle * - Performance Technologies*
95 Network Drive, Burlington, MA 01803
Email terry.don...@oracle.com <mailto:terry.don...@oracle.com>
