[mpich-discuss] nemesis on powerpc64?

[Dave Goodell]

FWIW I've got a version of the real ldarx/stdcx version cooked up on  
my laptop right now.  However we are right on a release boundary and  
I'm not sure they'll make it into the upcoming release of mpich2.  If  
you want to live on the edge and run with some unproven code, send me  
a mail off-list and I'll send you the current patch.

-Dave

On Sep 30, 2009, at 6:17 PM, Martin Siegert wrote:

> On Wed, Sep 30, 2009 at 09:39:23AM -0500, Dave Goodell wrote:
>> Something else just occurred to me.  With a sufficiently modern  
>> version of
>> GCC you should be able to get support via the GCC atomic intrinsic
>> functions.  This clearly isn't happening for some reason because
>> mutex-based emulation is being selected.  On the PPC970 login nodes  
>> here at
>> ANL we have GCC-4.1.2, which is new enough.  I believe that you need
>> GCC-4.1 or later to get the intrinsics.  Perhaps you have a later  
>> version
>> of the compiler somewhere on your system?
>
> You are absolutely right: problem solved.
> Our system is somewhat old (SLES 9) and the system gcc is 3.3.3.
> However, we have gcc-4.2.2 installed, thus all that was needed was to
> reconfigure with
>
> CC="gcc4 -m64"
>
> and now configure shows
>
> checking for support for gcc PowerPC atomics... no
> checking for support for gcc SiCortex atomics... no
> checking for support for gcc atomic intrinsics... yes
>
> and further down
>
> RUNNING CONFIGURE FOR THE NEMESIS CHANNEL
>
> Thanks a lot!
>
> Cheers,
> Martin
>
>> I don't know what the performance will be like.  Probably somewhere
>> in-between native ldarx/stdcx performance and mutex emulation  
>> because of
>> the full barrier semantics implied by the GCC API.
>>
>> -Dave
>>
>> On Sep 29, 2009, at 8:13 PM, Martin Siegert wrote:
>>
>>> Hi,
>>>
>>> I am trying to compile mpich2-1.1.1p1 with
>>> --with-device=ch3:nemesis
>>> on a PowerPC 64bit Linux system using CC="gcc -m64" and FC="xlf - 
>>> q64".
>>>
>>> configure fails with
>>> configure: error:
>>> The nemesis channel was selected yet no native atomic primitives are
>>> available on this platform.  OpenPA can emulate atomic primitives  
>>> using
>>> locks by specifying --with-atomic-primitives=no but performance  
>>> will be
>>> very poor.  This override should only be specified for correctness
>>> testing purposes.
>>>
>>> and src/openpa/config.log contains
>>>
>>> onfigure:6160: checking for support for gcc PowerPC atomics
>>> configure:6223: gcc -m64 -o conftest -O3 -mcpu=970 -mtune=970 - 
>>> maltivec
>>> -I./src -I/usr/local/src/mpich2-1.1.1p1/src/openpa/src
>>> -I/usr/local/src/mpich2-1.1.1p1/src/openpa/src -DUSE_PROCESS_LOCKS
>>> conftest.c -lpthread  -lpthread >&5
>>> In file included from conftest.c:41:
>>> src/primitives/opa_gcc_ppc.h: In function `OPA_LL_ptr':
>>> src/primitives/opa_gcc_ppc.h:80: error: duplicate case value
>>> src/primitives/opa_gcc_ppc.h:80: error: previously used here
>>> src/primitives/opa_gcc_ppc.h:82: warning: cast to pointer from  
>>> integer of
>>> different size
>>> src/primitives/opa_gcc_ppc.h: In function `OPA_SC_ptr':
>>> src/primitives/opa_gcc_ppc.h:90: error: duplicate case value
>>> src/primitives/opa_gcc_ppc.h:90: error: previously used here
>>> src/primitives/opa_gcc_ppc.h:92: warning: cast from pointer to  
>>> integer of
>>> different size
>>> configure:6230: $? = 1
>>>
>>> Line 80 in opa_gcc_ppc.h is:
>>>
>>> OPA_COMPILE_TIME_ASSERT(sizeof(int) == sizeof(void *));
>>>
>>> I am not sure whether I am interpreting this correctly, but this  
>>> looks
>>> to me as if this fails if sizeof(int) != sizeof(void *), i.e., on  
>>> any
>>> 64bit platform.
>>>
>>> Is there a fix for this?
>>>
>>> Thanks!
>>>
>>> Cheers,
>>> Martin
>>>
>>> -- 
>>> Martin Siegert
>>> Head, Research Computing
>>> WestGrid Site Lead
>>> IT Services                                phone: 778 782-4691
>>> Simon Fraser University                    fax:   778 782-4242
>>> Burnaby, British Columbia                  email: siegert at sfu.ca
>>> Canada  V5A 1S6