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...and because we are snobs about having Fortran values
in our code. ;-)
The reason you can't move ompi_bitmap to OPAL is because the limit is
tied to a Fortran quantity - and OPAL doesn't know anything about
Fortran. Or at least, officially it doesn't...
but the fact is that the Fortran limit is actually defined in
So the best solution would actually be to rename OMPI
_FORTRAN_HANDLE_MAX in opal_config.h to be OPAL_FORTRAN_HANDLE_MAX,
and replace opal_bitmap.c with the code in ompi_bitmap.c
(appropriately s/ompi/opal). Then this entire discussion can be tabled.
Hope that makes sense.
On Feb 3, 2009, at 1:30 PM, 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