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 the bitmap is initialized with the
size of the communicator, so it will _NEVER_ get expanded.
- in the PML (DR and OB1). Again the bitmap is initialized using the
number of processes, so it will _NEVER_ get expanded.
- in the attributes. This is the only place where the bitmap might
expand. However, as the current implementation is not thread safe and
as this call is outside the critical path, we can modify it in order
to expand the bitmap manually.
So, it appears that we don't really take advantage of the original
design for the bitmap. It might be time to revise it ...
On Feb 3, 2009, at 15:30 , Jeff Squyres wrote:
> 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 division and a modulo. Compared
>> with the cost of these two operation a quick test for a max bit is
>> In fact I think the safety limit if good for most cases. How about
>> having the max bit to the limit used to initialize the bitmap? We
>> can add a call to extend the bitmap in case some layer really need
>> to extend it, but restrict all others layers to the number of bits
>> requested when the bitmap is initialized.
> The problem with this is that the original design expands the bitmap
> whenever you try to set a bit that doesn't yet exist. So you'd need
> to track down every place in the code that exercises this assumption.
> You could set a max size if you want to (e.g., assuming you'll never
> have more than some_large_value of fortran handles [probably
> considerably less than the number of Fortran integers available], or
> Jeff Squyres
> Cisco Systems
> devel mailing list