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
opal_config.h!!
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.
Ralph
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
irrelevant.
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
somesuch).
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
