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 Nov 7, 2011, at 22:26 , Ralph Castain wrote:
> I didn't say the eventually wouldn't, George. I was trying to indicate that
> they may not be there yet, and our current code has been tested with their
> current releases - not what they eventually might release.
>
> As to who wanted this "stan
I didn't say the eventually wouldn't, George. I was trying to indicate that
they may not be there yet, and our current code has been tested with their
current releases - not what they eventually might release.
As to who wanted this "standard"...I was there during the discussions about
whether o
They better do conform to what they asked us to "accept". If wasn't that the
MPI Forum members were eager to put the tool interface into the standard, we
were kind of forced to. By whom … well by the tool vendors to promote a certain
homogeneity.
george.
On Nov 7, 2011, at 20:34 , Ralph Cast
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
I can't speak to what is in ompi_debuggers.c as I believe Jeff wrote most of
that. However, what is there has been tested and works with TotalView and a
couple of other debuggers.
Best guess: from what I've seen, most debuggers don't seem to conform to what
the MPI Forum has "accepted". It does
I was trying to understand how the debugger interface is supposed to work. And
if I was confused before, that feeling never disappeared.
There is one thing that I really can't figure out, and I hope that somebody
(Jeff/Ralph/Rolf based on svn blame) can enlighten me.
MPIR_debug_gate. In the doc
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
It is indeed good that you check for performance degradation. However, when a
__single__ BTL requires changes that affects all BTL/PML, you cannot just
assume an RFC is not necessary. This change affects all RDMA headers for all
BTL / PML, it is indeed a critical change even if it is not on the
No such luck for me, at least on Linux. I get linker errors when the
bufferevent code is deleted from the Makefile.am.
I'll commit what I have tonight. If someone else can find a way to omit
bufferevent, then that is welcome :-)
On Nov 7, 2011, at 11:58 AM, George Bosilca wrote:
> I might not
I might not get all the technical details here but I can confirm that your
commit (r25453) fixed all my issues. No more warnings, no ssl nor bufferevent.
george.
On Nov 7, 2011, at 12:55 , Ralph Castain wrote:
> I have this properly fixed now - will commit later tonight. In Nathan's
> defens
I have this properly fixed now - will commit later tonight. In Nathan's
defense, it turns out that the same configuration bug found here also exists in
the libevent207 component (the default one we have been using for a long time).
I won't bother fixing it as the commit deletes that component. W
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
Thats the nice thing about this change. Segments are only sent for larger
messages which is where we will need the extra bits.
And, you can blame Cray for their 128 bit memory registration key.
-Nathan
On Mon, 7 Nov 2011 09:22:58 -0500, Jeff Squyres wrote:
> This is probably why it would have b
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...
I'm fixing it now - I haven't seen those warnings before, and I've been using
this component for a long time now. But I do see a configure mistake and will
fix it.
On Nov 6, 2011, at 11:25 PM, Nathan T. Hjelm wrote:
> Hmm, I didn't come across that during testing. You are right that we
> should
This is probably why it would have 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 openib, sm, or vader (usin
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
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
This commit introduced quite a few warnings on Mac OS X. A snippet is attached
below. Btw, why do we need to build buffer event support in libevent? And why
ssl ...
../../../../../../ompi/opal/mca/event/libevent2013/libevent/bufferevent_openssl.c:
In function 'bio_bufferevent_read':
../../../..
27 matches
Mail list logo
