> Why do the symbols need to be weak? Remember that not all platforms
> support weak symbols.
I don't know. The way we currently pull MPIR symbols into orterun breaks
with some configuration. If we don't pull the symbols in then launchmon
can't attach to orterun. Moving the symbols to weak fixes
the keys, so I suppose
> both peers have to somehow reach a consensus outside the PML.
>
> george.
>
> On Nov 8, 2011, at 08:57 , Nathan T. Hjelm wrote:
>
>> Sure, I can do that. My only concern is with sending between hosts of
>> different endianness.
>>
On Tue, 8 Nov 2011 06:36:03 -0800, Rolf vandeVaart
wrote:
>> george.
>>
>>PS: Regarding the hand-copy instead of the memcpy, we tried to avoid
> using
>>memcpy in performance critical codes, especially when we know the size of
>>the data and the alignment. This relieves the compiler of adding u
on a PPE of RR later today.
-Nathan
On Tue, 8 Nov 2011 08:26:04 -0500, Jeff Squyres wrote:
> 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 se
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
x27;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 he
ave been good to RFC about this. :-)
>
> 8 bytes can/does affect short message latency, no?
>
>
>
> On Nov 6, 2011, at 11:29 PM, Nathan T. Hjelm wrote:
>
>> I saw no need for an rfc for r25445/r25448. I did not seen any
> performance
>> degradation with openi
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...
Hmm, I didn't come across that during testing. You are right that we
should't be compiling with ssl support.
On Mon, 7 Nov 2011 01:17:50 -0500, George Bosilca
wrote:
> This commit introduced quite a few warnings on Mac OS X. A snippet is
> attached below. Btw, why do we need to build buffer even
I saw no need for an rfc for r25445/r25448. I did not seen any performance
degradation with openib, sm, or vader (using ob1). Its only 8 bytes, and we
(LANL) will absolutely require a 128 bit key for the ugni btl.
Anyone else care to weigh in or do some measurements?
-Nathan
On Sun, 6 Nov 2011
10 matches
Mail list logo
