Thanks - very helpful. Rich
On 1/30/09 4:59 PM, "Ralph Castain" <r...@lanl.gov> wrote: > The history is simple. Originally, there was one bitmap_t in orte that > was also used in ompi. Then the folks working on Fortran found that > they had to put a limit in the bitmap code to avoid getting values > outside of Fortran's range. However, this introduced a problem - if we > had the limit in the orte version, then we limited ourselves > unnecessarily, and introduced some abstraction questions since orte > knows nothing about Fortran. > > So two were created. Then the orte_bitmap_t was blown away at a later > time when we removed the GPR as George felt it wasn't necessary (which > was true). It was later reborn when we needed it in the routed system, > but this time it was done in opal as others indicated a potential more > general use for that capability. > > The problem with uniting the two is that you either have to introduce > Fortran-based limits into opal (which messes up the non-ompi uses), or > deal with the Fortran limits in some other fashion. Neither is > particularly pleasant, though it could be done. > > I think it primarily is a question for the Fortran folks to address - > can they deal with Fortran limits in some other manner without making > the code unmanageable and/or taking a performance hit? > > Ralph > > > On Jan 30, 2009, at 2:40 PM, Richard Graham wrote: > >> This should really be viewed as a code maintenance RFC. The reason >> this >> came up in the first place is because we are investigating the btl >> move, but >> these are really two very distinct issues. There are two bits of >> code that >> have virtually the same functionality - they do have the same >> interface I am >> told. The question is, is there a good reason to keep two different >> versions in the repository ? Not knowing the history of why a second >> version was created this is an inquiry. Is there some performance >> advantage, or some other advantage to having these two versions ? >> >> Rich >> >> >> On 1/30/09 3:23 PM, "Terry D. Dontje" <terry.don...@sun.com> wrote: >> >>> I second Brian's concern. So unless this is just an announcement >>> that >>> this is being done on a tmp branch only until everything is in >>> order I >>> think we need further discussions. >>> >>> --td >>> >>> Brian Barrett wrote: >>>> So once again, I bring up my objection of this entire line of moving >>>> until such time as the entire process is properly mapped out. I >>>> believe it's premature to being moving around code in preparation >>>> for >>>> a move that hasn't been proven viable yet. Until there is concrete >>>> evidence that such a move is possible, won't degrade application >>>> performance, and does not make the code totally unmaintainable, I >>>> believe that any related code changes should not be brought into the >>>> trunk. >>>> >>>> Brian >>>> >>>> >>>> On Jan 30, 2009, at 12:30 PM, Rainer Keller wrote: >>>> >>>>> On behalf of Laurent Broto >>>>> >>>>> RFC: Move of ompi_bitmap_t >>>>> >>>>> WHAT: Move ompi_bitmap_t into opal or onet-layer >>>>> >>>>> WHY: Remove dependency on ompi-layer. >>>>> >>>>> WHERE: ompi/class >>>>> >>>>> WHEN: Open MPI-1.4 >>>>> >>>>> TIMEOUT: February 3, 2009. >>>>> >>>>> ------------------------------------- >>>>> Details: >>>>> WHY: >>>>> The ompi_bitmap_t is being used in various places within >>>>> opal/orte/ompi. With >>>>> the proposed splitting of BTLs into a separate library, we are >>>>> currently >>>>> investigating several of the differences between ompi/class/* and >>>>> opal/class/* >>>>> >>>>> One of the items is the ompi_bitmap_t which is quite similar to the >>>>> opal_bitmap_t. >>>>> The question is, whether we can remove favoring a solution just >>>>> in opal. >>>>> >>>>> WHAT: >>>>> The data structures in the opal-version are the same, >>>>> so is the interface, >>>>> the implementation is *almost* the same.... >>>>> >>>>> The difference is the Fortran handles ;-]! >>>>> >>>>> Maybe we're missing something but could we have a discussion, on >>>>> why >>>>> Fortran >>>>> sizes are playing a role here, and if this is a hard requirement, >>>>> how >>>>> we could >>>>> settle that into that current interface (possibly without a >>>>> notion of >>>>> Fortran, >>>>> but rather, set some upper limit that the bitmap may grow to?) >>>>> >>>>> With best regards, >>>>> Laurent and Rainer >>>>> -- >>>>> ------------------------------------------------------------------------ >>>>> Rainer Keller, PhD Tel: (865) 241-6293 >>>>> Oak Ridge National Lab Fax: (865) 241-4811 >>>>> PO Box 2008 MS 6164 Email: kel...@ornl.gov >>>>> Oak Ridge, TN 37831-2008 AIM/Skype: rusraink >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
