On Jun 7, 2010, at 10:29 PM, George Bosilca wrote:
> How did we ended up with the following situation:
>
> -libmca_common_sm_so_version=1:0:0
> -libmca_common_mx_so_version=0:0:0
> +libmca_common_sm_so_version=2:0:0
> +libmca_common_mx_so_version=1:0:0
>
> Where the same type of component (commo
Here's the file I used:
#include
int foo(void) {
int32_t oldval, delta;
int32_t *addr = 0;
do {
oldval = *addr;
} while (0 == opal_atomic_cmpset_32(addr, oldval, oldval + delta));
return (oldval + delta);
}
Here's the assembly it produced (note that this is pgi 7.0.7 -- later
The inline was ignored, and the code for the opal_atomic_cmpset_32 is not in
there ...
george.
On Jun 8, 2010, at 12:11 , Jeff Squyres wrote:
> Here's the file I used:
>
> #include
>
> int foo(void) {
> int32_t oldval, delta;
> int32_t *addr = 0;
> do {
> oldval = *addr;
> } whi
What exactly do you need? Your first mail said:
> >> Can you send the assembly instructions generated by the PGI compiler for
> >> the following code:
> >>
> >> int32_t oldval;
> >>
> >> do {
> >> oldval = *addr;
> >> } while (0 == opal_atomic_cmpset_32(addr, oldval, oldval + delta))
I was hoping to see the actual inlined assembly for the code. Here is what gcc
output:
LFB3:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
movl$0, -4(%rbp)
leaq-4(%rbp), %rcx
.align 4,0x90
L2:
movl-4(%rbp), %eax
leal1(%rax),
On Jun 8, 2010, at 9:53 AM, George Bosilca wrote:
> As you can see there is no explicit call, the opal_atomic_cmpset_32 is really
> inlined. I think the problem is that you didn't specify the -O3 flag on your
> command line.
Ah, you wanted me to compile the OMPI code itself and send you the ass
Still no good, the opal_atomic_cmpset_32 is not inlined. Try to add -O3 to your
command line, this helped for gcc.
Thanks,
george.
On Jun 8, 2010, at 14:14 , Jeff Squyres wrote:
> On Jun 8, 2010, at 9:53 AM, George Bosilca wrote:
>
>> As you can see there is no explicit call, the opal_at
Look at my output -- I did...
On Jun 8, 2010, at 10:40 AM, George Bosilca wrote:
> Still no good, the opal_atomic_cmpset_32 is not inlined. Try to add -O3 to
> your command line, this helped for gcc.
>
> Thanks,
> george.
>
> On Jun 8, 2010, at 14:14 , Jeff Squyres wrote:
>
> > On Jun 8
It didn't work. Let's try with this small complete application:
#include
#define SMPLOCK "lock;"
static inline int opal_atomic_cmpset_32( volatile int32_t *addr,
int32_t oldval, int32_t newval)
{
unsigned char ret;
__asm__ __volatile__ (
Oops -- I see the problem; I used "-s" instead of "-S". So that old output I
sent you was kinda meaningless; it was from some other test. Sorry! :-(
But your test is much smaller and easier to check, so let's do that:
-
[7:49] svbu-mpi:~/tmp % cat george2.c
#include
#define SMPLOCK "lo
On Jun 8, 2010, at 14:49 , Jeff Squyres wrote:
> ## -cmdline +pgcc george2.c -O3 -c -S -x 123 4 -x 123 0x8000
> -alwaysinline /opt/pgi/7.0.7/linux86-64/7.0-7/lib/libintrinsics.il 4
> ## -asm george2.s
> ## lineno: 7
> .text
> .align 16
> opal_atomic_cmpset_32:
> ..Dcfb0:
>
We talked about this on the phone on the call today. I filed
https://svn.open-mpi.org/trac/ompi/ticket/2437 about what we plan to do.
On Jun 8, 2010, at 11:40 AM, George Bosilca wrote:
>
> On Jun 8, 2010, at 14:49 , Jeff Squyres wrote:
>
> > ## -cmdline +pgcc george2.c -O3 -c -S -x 123 4 -x
We talked about this on the call today. This proposal was generally accepted.
I put more details on the following two tickets:
https://svn.open-mpi.org/trac/ompi/ticket/2429
https://svn.open-mpi.org/trac/ompi/ticket/2438
On Jun 4, 2010, at 11:47 AM, Jeff Squyres (jsquyres) wrote:
> On Jun 2
Jeff Squyres wrote:
We talked about this on the phone on the call today. I filed
https://svn.open-mpi.org/trac/ompi/ticket/2437 about what we plan to do.
What does "disabling threads" mean? E.g., does it mean disabling single
receive queues? Sorry for asking bonehead questions, but I tho
14 matches
Mail list logo
