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 ...
george.
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
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
