On 7/22/13 9:19 AM, "David Goodell (dgoodell)" wrote:
>On Jul 20, 2013, at 4:42 PM, "Barrett, Brian W"
>wrote:
>
>> On 7/20/13 3:33 PM, "George Bosilca" wrote:
>>
>>> - In terms of memory this solution provide an approach where there
>>>will never be an extra overhead. The ompi_proc_t is not c
On Jul 20, 2013, at 4:42 PM, "Barrett, Brian W" wrote:
> On 7/20/13 3:33 PM, "George Bosilca" wrote:
>
>> - In terms of memory this solution provide an approach where there will
>> never be an extra overhead. The ompi_proc_t is not changed, and the extra
>> array of endpoints is only created
On 7/20/13 3:33 PM, "George Bosilca"
mailto:bosi...@icl.utk.edu>> wrote:
- The cost of accessing the endpoints will be a load from the ompi_proc_t to
get that global index and then another relative load (using this index and the
array of endpoints). So exactly the same number of loads as the d
On Jul 19, 2013, at 19:29 , "Barrett, Brian W" wrote:
> On 7/19/13 10:58 AM, "George Bosilca" wrote:
>
>> 1. The BML endpoint structure (aka. BML proc) is well known and defined
>> in the bml.h. So it is not technically opaqueŠ
>
> It's opaque in that outside of the R2 BML, users were not sup
On 7/19/13 10:58 AM, "George Bosilca" wrote:
>1. The BML endpoint structure (aka. BML proc) is well known and defined
>in the bml.h. So it is not technically opaque
It's opaque in that outside of the R2 BML, users were not supposed to poke
at what's in proc_bml without using the BML interface.
On 7/18/13 7:39 PM, "Ralph Castain"
mailto:r...@open-mpi.org>> wrote:
We are looking at exascale requirements, and one of the big issues is memory
footprint. We currently retrieve the endpoint info for every process in the
job, plus all the procs in any communicator with which we do a connect/a
