On Thu, July 26, 2007 2:07 pm, Brian Barrett wrote:
> On Jul 26, 2007, at 1:01 PM, Mohamad Chaarawi wrote:
>
>>
>> On Thu, July 26, 2007 1:18 pm, Brian Barrett wrote:
>>> On Jul 26, 2007, at 12:00 PM, Mohamad Chaarawi wrote:
>>>
> 2) I think it would be better to always have the flags and
On Jul 26, 2007, at 1:01 PM, Mohamad Chaarawi wrote:
On Thu, July 26, 2007 1:18 pm, Brian Barrett wrote:
On Jul 26, 2007, at 12:00 PM, Mohamad Chaarawi wrote:
2) I think it would be better to always have the flags and macros
available (like OMPI_GROUP_SPORADIC and OMPI_GROUP_IS_SPORADIC)
On Thu, July 26, 2007 1:18 pm, Brian Barrett wrote:
> On Jul 26, 2007, at 12:00 PM, Mohamad Chaarawi wrote:
>
>>> 2) I think it would be better to always have the flags and macros
>>> available (like OMPI_GROUP_SPORADIC and OMPI_GROUP_IS_SPORADIC) even
>>> when sparse groups are disabled. They
On Jul 26, 2007, at 12:00 PM, Mohamad Chaarawi wrote:
2) I think it would be better to always have the flags and macros
available (like OMPI_GROUP_SPORADIC and OMPI_GROUP_IS_SPORADIC) even
when sparse groups are disabled. They dont' take up any space, and
mean less #ifs in the general code
On Thu, July 26, 2007 12:20 pm, Brian Barrett wrote:
> Mohamad -
>
> A couple of comments / questions:
>
> 1) Why do you need the #if OMPI_GROUP_SPARSE in communicator/comm.c?
> That seems like
> part of the API that should under no conditions change based on
> sparse/not sparse
>
I don't,
Mohamad -
A couple of comments / questions:
1) Why do you need the #if OMPI_GROUP_SPARSE in communicator/comm.c?
That seems like
part of the API that should under no conditions change based on
sparse/not sparse
2) I think it would be better to always have the flags and macros
Sorry the additional parameters are 5 integers and 3 pointers..
Mohamad
On Wed, July 25, 2007 9:45 pm, Mohamad Chaarawi wrote:
> In the current code, almost all #ifs are due to the fact that we don't
> want to add the extra memory by the sparse parameters that are added to
> the group structure.
In the current code, almost all #ifs are due to the fact that we don't
want to add the extra memory by the sparse parameters that are added to
the group structure.
The additional parameters are 5 pointers and 3 integers.
If nobody objects, i would actually keep those extra parameters, even if
On Jul 25, 2007, at 3:14 PM, Jeff Squyres wrote:
On Jul 25, 2007, at 5:07 PM, Brian Barrett wrote:
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
On Jul 25, 2007, at 5:07 PM, Brian Barrett wrote:
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
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
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
This is good work, so I am happy to see it come over. My initial
understanding was that
there would be compile time protection for this. In the absence of this, I
think we need
to see performance data on a variety of communication substrates. It seems
like a latency
measurement is, perhaps,
13 matches
Mail list logo
