Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Brian Barrett (bbarrett_at_[hidden])
Date: 2007-07-25 17:07:20

On Jul 25, 2007, at 2:56 PM, Jeff Squyres wrote:

> On Jul 25, 2007, at 10:39 AM, Brian Barrett wrote:
>> I have an even bigger objection than Rich. It's near impossible to
>> measure the latency impact of something like this, but it does have
>> an additive effect. It doesn't make sense to have all that code in
>> the critical path for systems where it's not needed. We should leave
>> the compile time decision available, unless there's a very good
>> reason (which I did not see in this e-mail) to remove it.
> It just adds a lot of #if's throughout the code. Other than that,
> there's no reason to remove it.

I agree, lots of #ifs are bad. But I guess I don't see the problem.
The only real important thing people were directly accessing in the
ompi_group_t is the array of proc pointers. Indexing into them could
be done with a static inline function that just has slightly
different time complexity based on compile options. Static inline
function that just does an index in the group proc pointer would have
almost no added overhead (none if the compiler doesn't suck).