I do not recall, and from the code there is no obvious reason. However, being
able to store multiple smaller members might be a good enough reason.
Btw, we don't use the key8 at all. I guess we can clean that code up to only
keep key32 and key64, eventually with the count to match up the right s
Ok, that makes sense. Is there a reason why the members were all set the be
the same size?
Maybe seg_key should be:
union {
uint8_t key8;
uint16_t key16;
uint32_t key32;
uint64_t key64;
struct { uint64_t value[2] } key128;
};
-Nathan
On Tue, 8 Nov 2011 17:22:48 -0500, George Bosilca
Elements in an array are always stored in the expected [increasing] order,
regardless of the endianess of the architecture. Moreover, due to the alignment
rules, all members in a union will start at the same address.
It turns out there is no endianess conversion on the keys, so I suppose both
p
Sure, I can do that. My only concern is with sending between hosts of
different endianness.
For example, if seg_key is 128 bits wide and the key32 is 64 bits then we
might run into this:
Host 1: (big endian)
Set seg_key.key32[0] = 0x
would result in seg_key: 0x 0x 0x1
On Nov 7, 2011, at 9:48 PM, Nathan T. Hjelm wrote:
> In retrospect I should have done a RFC for the 3rd change with a short
> timeout. At the time (operating on little sleep) it seemed like the commits
> would have minimal impact. Please let me know if the commits have any
> negative impact.
FWIW
On 11/7/11 8:58 PM, "George Bosilca" wrote:
>I'll take as an example the atomic operations. They exist only on amd64,
>and only if the compiler supports gcc-like assembly. However, the atomic
>operation is defined in a global header with a very exciting name
>atomic.h. If anybody else start using
There is one major reason, if you look at them as a whole they look half-baked.
And we are not supposed to accept such commits in the trunk. Development
branches are the way to go, propose coherent and complete patches. Bringing
disconnected pieces, and claiming that magically they will compose
On Mon, 7 Nov 2011 17:18:42 -0500, George Bosilca
wrote:
> A little bit of history:
>
> 1. r25305: added 2 atomic operations to OPAL. However, they only exists
on
> amd64 and are only used in the vader BTL, which I assume only supports
> amd64.
Two things:
- The atomic is a new feature that h
On Nov 7, 2011, at 17:34 , Barrett, Brian W wrote:
> I'm not sure why they called it vader, but vader is a fairly straight
> forward shared memory BTL. It differs from sm in two important ways: 1)
> it uses the XPMEM driver instead of SysV for shared memory and 2) it uses
> the the Nemesis queue
On Nov 7, 2011, at 17:34 , Barrett, Brian W wrote:
> A number of OMPI developer institutions are working on a new BTL
> (different from vader) for the Cray XE series using the uGNI upper layer.
> The rkeys in uGNI are 128 bytes.
Thanks Brian for the clarification.
Obviously there was no need fo
On 11/7/11 3:27 PM, "George Bosilca" wrote:
>
>On Nov 7, 2011, at 10:37 , Jeff Squyres wrote:
>
>> On Nov 7, 2011, at 10:16 AM, Nathan T. Hjelm wrote:
>>
>>> Yes, and I completely agree. I was simply trying to keep it consistent
>>>in
>>> case there is something I don't know about the heterogene
On Nov 7, 2011, at 10:37 , Jeff Squyres wrote:
> On Nov 7, 2011, at 10:16 AM, Nathan T. Hjelm wrote:
>
>> Yes, and I completely agree. I was simply trying to keep it consistent in
>> case there is something I don't know about the heterogeneous case.
>>
>> I increased the size of the 64 bit memb
A little bit of history:
1. r25305: added 2 atomic operations to OPAL. However, they only exists on
amd64 and are only used in the vader BTL, which I assume only supports amd64.
2. r25334: The seg_key union got a new member ptr. This member is solely used
in the vader BTL, as all other BTL use
On Nov 7, 2011, at 10:16 AM, Nathan T. Hjelm wrote:
> Yes, and I completely agree. I was simply trying to keep it consistent in
> case there is something I don't know about the heterogeneous case.
>
> I increased the size of the 64 bit member because there is no uint128 type.
Ah, I see.
I would
Yes, and I completely agree. I was simply trying to keep it consistent in
case there is something I don't know about the heterogeneous case.
I increased the size of the 64 bit member because there is no uint128 type.
-Nathan
On Mon, 7 Nov 2011 10:00:27 -0500, Jeff Squyres wrote:
> It's a union,
It's a union, right? So the size increase (and type change for the 64 value)
shouldn't have been necessary.
On Nov 7, 2011, at 9:56 AM, Nathan T. Hjelm wrote:
> Just keeping it consistent with the existing code. Thought it might be
> necessary for heterogenous.
>
> -Nathan
>
> On Mon, 7 Nov
Just keeping it consistent with the existing code. Thought it might be
necessary for heterogenous.
-Nathan
On Mon, 7 Nov 2011 09:14:21 -0500, Jeff Squyres wrote:
> Just curious -- why was it necessary to increase the size of the 8, 32,
and
> 64 arrays?
>
>
> On Nov 6, 2011, at 11:19 AM, hje...
Just curious -- why was it necessary to increase the size of the 8, 32, and 64
arrays?
On Nov 6, 2011, at 11:19 AM, hje...@osl.iu.edu wrote:
> Author: hjelmn
> Date: 2011-11-06 11:19:09 EST (Sun, 06 Nov 2011)
> New Revision: 25445
> URL: https://svn.open-mpi.org/trac/ompi/changeset/25445
>
> L
18 matches
Mail list logo
