> 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.Dontje_at_[hidden]> 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: keller_at_[hidden]
>>>>> Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel_at_[hidden]
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel>>>>>
>>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel