Ah; I thought this data structure was used for the fortran MPI object
handles as well, but looking at the code now, I see that
opal_pointer_array's are used for that. The only Fortran place it is
used is for attributes.
I see ompi_bitmap_t used for attributes, BTL reachability
computatio
o is supposed to
> >>> - first test if the max size has been set,
> >>> - then ensure that the bitmap never grows beyond that size.
> >>>
> >>> In the first approach we only do one test, in the second one, always
> >>> one and sometimes
2009 7:37 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
I just looked through both opal_bitmap_t and ompi_bitmap_t and I
think
that the only real difference is that in the ompi version, we check
(in various places) that the size of the bitmap never grows beyo
These places are easy to find and track. I did it on the ORTE layer,
and in this context the bitmap is _NOT_ required to grow as all
bitmaps are initialize with the number of processes in the jobid. In
the OMPI layer there are few places using the bitmap:
- the hierarch collective. There th
Let's keep something in mind. Tim W and I hammered at this topic for a
long, long time. The fact is that there is nothing in the usage of
opal_bitmap that would in any way be hampered by the limit imposed in
ompi_bitmap. We just don't use ompi_bitmap in orte because it is in
the OMPI layer.
first test if the max size has been set,
>>> - then ensure that the bitmap never grows beyond that size.
>>>
>>> In the first approach we only do one test, in the second one, always
>>> one and sometimes two.
>>>
>>> But may I miss something...
>>>
>
On Feb 3, 2009, at 3:24 PM, George Bosilca wrote:
In the current bitmap implementation every time we set or check a
bit we have to compute the index of the char where this bit is set
and the relative position from the beginning of char. This requires
two _VERY_ expensive operations: a divis
two.
But may I miss something...
What do you think about this ?
--
Laurent
-Original Message-
From: devel-boun...@open-mpi.org on behalf of Jeff Squyres
Sent: Sun 2/1/2009 7:37 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
I just looked through both op
.
>>
>> Rich
>>
>> - Original Message -----
>> From: devel-boun...@open-mpi.org
>> To: Open MPI Developers
>> Sent: Sun Feb 01 10:36:33 2009
>> Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
>>
>> In that case, I remove my objection t
ichard L. wrote:
Brian,
Just fyi, there is a weekly call - thursdays at 4 est where we have
been discussyng these issues.
Let's touch base at the forum.
Rich
- Original Message -
From: devel-boun...@open-mpi.org
To: Open MPI Developers
Sent: Sun Feb 01 10:36:33 2009
Subject: Re: [O
g on behalf of Jeff Squyres
Sent: Sun 2/1/2009 7:37 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
I just looked through both opal_bitmap_t and ompi_bitmap_t and I think
that the only real difference is that in the ompi version, we check
(in various places) that the
t; Rich
>> >
>> > ----- Original Message -----
>> > From: devel-boun...@open-mpi.org
>> > To: Open MPI Developers
>> > Sent: Sun Feb 01 10:36:33 2009
>> > Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
>> >
>> > In that c
When you heading over to my parents' ?
Jerry
- Original Message -
From: devel-boun...@open-mpi.org
To: de...@open-mpi.org
Sent: Sun Feb 01 12:14:31 2009
Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
Brian,
Just fyi, there is a weekly call - thursdays at 4 est where we
se at the forum.
Rich
- Original Message -
From: devel-boun...@open-mpi.org
To: Open MPI Developers
Sent: Sun Feb 01 10:36:33 2009
Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
In that case, I remove my objection to this particular RFC. It
remains for all other RFCs related to mo
Brian,
Just fyi, there is a weekly call - thursdays at 4 est where we have been
discussyng these issues.
Let's touch base at the forum.
Rich
- Original Message -
From: devel-boun...@open-mpi.org
To: Open MPI Developers
Sent: Sun Feb 01 10:36:33 2009
Subject: Re: [OMPI devel
--
Laurent
-Original Message-
From: devel-boun...@open-mpi.org on behalf of Jeff Squyres
Sent: Sun 2/1/2009 7:37 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
I just looked through both opal_bitmap_t and ompi_bitmap_t and I think
that the only real difference
In that case, I remove my objection to this particular RFC. It
remains for all other RFCs related to moving any of the BTL move code
to the trunk before the critical issues with the BTL move have been
sorted out in a temporary branch. This includes renaming functions
and such. Perhaps we
I just looked through both opal_bitmap_t and ompi_bitmap_t and I think
that the only real difference is that in the ompi version, we check
(in various places) that the size of the bitmap never grows beyond
OMPI_FORTRAN_HANDLE_MAX; the opal version doesn't do these kind of
size checks.
I t
Thanks - very helpful.
Rich
On 1/30/09 4:59 PM, "Ralph Castain" 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 o
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
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
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 th
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
23 matches
Mail list logo
