Ralph Castain wrote:
To be clear, I wasn't implying anyone would intentionally break rank_file. However, it is rarely (if ever?) tested before we release - AFAIK, none of the MTT tests run by the community test this feature. Thus, it inevitably breaks without detection as changes are made elsewhere in the system. We typically don't know it is broken until someone complains about it, which usually is several months after the release.

Fair enough.  I guess my yellow fever shot has made me cranky today.

So I'll stand by my "self deprecate" comment. It has been the history of this feature, and I don't see anything changing to improve that situation.

Now if you implement a replacement... :-)
I'll get right on that after you approve the RFC that I am also suppose to send out :-).

-td

On Apr 16, 2010, at 5:08 AM, Terry Dontje wrote:

Jeff Squyres wrote:
On Apr 16, 2010, at 6:43 AM, Terry Dontje wrote:

  
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.
    

Er... no.

There is nothing nefarious going on here.  Ralph and I were just chatting yesterday about some process affinity issues and the topic of rank_file came up (again).  Remember that rank_file was a "throw over the wall" kind of code contribution and has historically been difficult to maintain.  Neither of us were excited at the prospect of adding hyperthreading support (once hwloc is finally released -- unfortunately, it's blocking on me, at the moment...) and also having to extend rank file to support it.

I asked Ralph if we should deprecate rank_file since the other binding options are available.  He assumed (correctly, it turns out) that no one would go for that.  But I figured I'd ask anyway.

I think all Ralph is saying is that we're (I'm) likely to add hyperthreading support in the not-distant future (and maybe Oracle will add support for boards).  This work is not likely to *break* rank_file, but neither of us are excited about extending rank_file to support hyperthreading.  If no one else steps up to extend it, then it may become obsolete over time because it doesn't support the things that people want.

  
I am ok with the above. 
Terry -- perhaps it's time to resurrect the new processor affinity proposal that you've been promising me for many months.  If rank_file were replaced with Something Better, I'd certainly be happy.  ;-)

  
Can we then have Ralph implement it :-)...  That was a joke Ralph!!!


--
<Mail Attachment.gif>
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.650.633.7054
Oracle - Performance Technologies
95 Network Drive, Burlington, MA 01803
Email terry.dontje@oracle.com

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


_______________________________________________ devel mailing list devel@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.dontje@oracle.com