Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-02-03 15:30:03


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