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).
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?
For corporate legal information go to:
devel mailing list
devel mailing list
Terry D. Dontje | Principal Software Engineer
Engineering | +1.650.633.7054
95 Network Drive, Burlington, MA 01803