Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

Well, the contents of opal/asm/asm-data.txt and the arch-specific subdirs
below opal/include/opal/sys have served me as a list of the atomics
implementations.  If those include architectures no longer officially
supported, then some cleanup may be in order (as SPARC_v8 was recently
removed from asm-data.txt).

-Paul


On Mon, Aug 11, 2014 at 11:44 AM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:

> I think the closest thing we have to a supported architecture list is in
> the README.
>
>
> On Aug 11, 2014, at 2:42 PM, Nathan Hjelm  wrote:
>
> >
> > Which brings us back to Dave's question. Is there a list of supported
> > architectures? I don't want to bother with DEC Alpha if we no longer
> > support it.
> >
> > BTW, so far I have converted: AMD64, IA32, ARM. Working on IA64 now.
> >
> > -Nathan
> >
> > On Mon, Aug 11, 2014 at 01:57:21PM -0400, George Bosilca wrote:
> >>   Dave,
> >>   We all understand your concerns. However, the current issue has
> nothing to
> >>   do with Nathan, the code for supporting ARMv5 is already in the patch
> I
> >>   submitted and that Paul validated.
> >>   What Nathan said he might take a look at is a different method for
> >>   generating assembly code, one that only supports ARMv7 and later.
> >> George.
> >>
> >>   On Mon, Aug 11, 2014 at 1:51 PM, Dave Goodell (dgoodell)
> >>    wrote:
> >>
> >> On Aug 11, 2014, at 11:54 AM, Paul Hargrove 
> wrote:
> >>
> >>> I am on the same page with George here - if it's on the list then
> >> support it until its been removed.
> >>>
> >>> I happen to have systems to test, I believe, every supported atomics
> >> implementation except for DEC Alpha, and so I did test them all.
> >>
> >> My comment was not intended to indicate that I don't value your
> testing
> >> contributions, Paul.  I am more concerned that Nathan is wasting
> time
> >> fixing support for an effectively useless platform.  It's not like
> this
> >> is a case where making the more portable change improves our general
> >> correctness on other platforms; it's a very (<= ARMv5)-specific
> >> situation.
> >>
> >> If there's actually an official list of supported platforms
> somewhere,
> >> then I'll let Nathan decide whether he wants to submit an RFC to
> drop
> >> ARMv5 support.  I know I'd support it, but I don't care enough to
> write
> >> an RFC of my own right now.
> >> -Dave
> >>
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> Link to this post:
> >> http://www.open-mpi.org/community/lists/devel/2014/08/15618.php
> >
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15619.php
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15620.php
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15621.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Jeff Squyres (jsquyres)]

I think the closest thing we have to a supported architecture list is in the 
README.


On Aug 11, 2014, at 2:42 PM, Nathan Hjelm  wrote:

> 
> Which brings us back to Dave's question. Is there a list of supported
> architectures? I don't want to bother with DEC Alpha if we no longer
> support it.
> 
> BTW, so far I have converted: AMD64, IA32, ARM. Working on IA64 now.
> 
> -Nathan
> 
> On Mon, Aug 11, 2014 at 01:57:21PM -0400, George Bosilca wrote:
>>   Dave,
>>   We all understand your concerns. However, the current issue has nothing to
>>   do with Nathan, the code for supporting ARMv5 is already in the patch I
>>   submitted and that Paul validated.
>>   What Nathan said he might take a look at is a different method for
>>   generating assembly code, one that only supports ARMv7 and later.
>> George.
>> 
>>   On Mon, Aug 11, 2014 at 1:51 PM, Dave Goodell (dgoodell)
>>    wrote:
>> 
>> On Aug 11, 2014, at 11:54 AM, Paul Hargrove  wrote:
>> 
>>> I am on the same page with George here - if it's on the list then
>> support it until its been removed.
>>> 
>>> I happen to have systems to test, I believe, every supported atomics
>> implementation except for DEC Alpha, and so I did test them all.
>> 
>> My comment was not intended to indicate that I don't value your testing
>> contributions, Paul.  I am more concerned that Nathan is wasting time
>> fixing support for an effectively useless platform.  It's not like this
>> is a case where making the more portable change improves our general
>> correctness on other platforms; it's a very (<= ARMv5)-specific
>> situation.
>> 
>> If there's actually an official list of supported platforms somewhere,
>> then I'll let Nathan decide whether he wants to submit an RFC to drop
>> ARMv5 support.  I know I'd support it, but I don't care enough to write
>> an RFC of my own right now.
>> -Dave
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/08/15618.php
> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/08/15619.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/08/15620.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Nathan Hjelm]

Which brings us back to Dave's question. Is there a list of supported
architectures? I don't want to bother with DEC Alpha if we no longer
support it.

BTW, so far I have converted: AMD64, IA32, ARM. Working on IA64 now.

-Nathan

On Mon, Aug 11, 2014 at 01:57:21PM -0400, George Bosilca wrote:
>Dave,
>We all understand your concerns. However, the current issue has nothing to
>do with Nathan, the code for supporting ARMv5 is already in the patch I
>submitted and that Paul validated.
>What Nathan said he might take a look at is a different method for
>generating assembly code, one that only supports ARMv7 and later.
>  George.
> 
>On Mon, Aug 11, 2014 at 1:51 PM, Dave Goodell (dgoodell)
> wrote:
> 
>  On Aug 11, 2014, at 11:54 AM, Paul Hargrove  wrote:
> 
>  > I am on the same page with George here - if it's on the list then
>  support it until its been removed.
>  >
>  > I happen to have systems to test, I believe, every supported atomics
>  implementation except for DEC Alpha, and so I did test them all.
> 
>  My comment was not intended to indicate that I don't value your testing
>  contributions, Paul.  I am more concerned that Nathan is wasting time
>  fixing support for an effectively useless platform.  It's not like this
>  is a case where making the more portable change improves our general
>  correctness on other platforms; it's a very (<= ARMv5)-specific
>  situation.
> 
>  If there's actually an official list of supported platforms somewhere,
>  then I'll let Nathan decide whether he wants to submit an RFC to drop
>  ARMv5 support.  I know I'd support it, but I don't care enough to write
>  an RFC of my own right now.
>  -Dave
> 
>  ___
>  devel mailing list
>  de...@open-mpi.org
>  Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>  Link to this post:
>  http://www.open-mpi.org/community/lists/devel/2014/08/15618.php

> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/08/15619.php



pgpNT3o5fHIcB.pgp
Description: PGP signature

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

Dave,

We all understand your concerns. However, the current issue has nothing to
do with Nathan, the code for supporting ARMv5 is already in the patch I
submitted and that Paul validated.

What Nathan said he might take a look at is a different method for
generating assembly code, one that only supports ARMv7 and later.

  George.



On Mon, Aug 11, 2014 at 1:51 PM, Dave Goodell (dgoodell)  wrote:

> On Aug 11, 2014, at 11:54 AM, Paul Hargrove  wrote:
>
> > I am on the same page with George here - if it's on the list then
> support it until its been removed.
> >
> > I happen to have systems to test, I believe, every supported atomics
> implementation except for DEC Alpha, and so I did test them all.
>
> My comment was not intended to indicate that I don't value your testing
> contributions, Paul.  I am more concerned that Nathan is wasting time
> fixing support for an effectively useless platform.  It's not like this is
> a case where making the more portable change improves our general
> correctness on other platforms; it's a very (<= ARMv5)-specific situation.
>
> If there's actually an official list of supported platforms somewhere,
> then I'll let Nathan decide whether he wants to submit an RFC to drop ARMv5
> support.  I know I'd support it, but I don't care enough to write an RFC of
> my own right now.
>
> -Dave
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15618.php
>

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Dave Goodell (dgoodell)]

On Aug 11, 2014, at 11:54 AM, Paul Hargrove  wrote:

> I am on the same page with George here - if it's on the list then support it 
> until its been removed.
> 
> I happen to have systems to test, I believe, every supported atomics 
> implementation except for DEC Alpha, and so I did test them all.

My comment was not intended to indicate that I don't value your testing 
contributions, Paul.  I am more concerned that Nathan is wasting time fixing 
support for an effectively useless platform.  It's not like this is a case 
where making the more portable change improves our general correctness on other 
platforms; it's a very (<= ARMv5)-specific situation.

If there's actually an official list of supported platforms somewhere, then 
I'll let Nathan decide whether he wants to submit an RFC to drop ARMv5 support. 
 I know I'd support it, but I don't care enough to write an RFC of my own right 
now.

-Dave

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

I am on the same page with George here - if it's on the list then support
it until its been removed.

I happen to have systems to test, I believe, every supported atomics
implementation except for DEC Alpha, and so I did test them all.

AFAIK ARMv5 is even out-dated as a smartphone platform.

-Paul


On Mon, Aug 11, 2014 at 9:46 AM, George Bosilca  wrote:

> It is not that I care, but it was one of our supported platforms and we
> don't usually drop support for anything without a proper RFC.
>
>   George.
>
>
>
>
> On Mon, Aug 11, 2014 at 12:09 PM, Dave Goodell (dgoodell) <
> dgood...@cisco.com> wrote:
>
>> On Aug 7, 2014, at 11:37 PM, George Bosilca  wrote:
>>
>> > Paul's tests identified an small issue with the previous patch (a real
>> corner-case for ARM v5). The patch below is fixing all known issues.
>>
>> Wait, why do we care about ARMv5?  It's certainly not a serious HPC
>> platform, nor is it even a relevant laptop platform at this point (AFAIK).
>>
>> -Dave
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/08/15614.php
>>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15615.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

It is not that I care, but it was one of our supported platforms and we
don't usually drop support for anything without a proper RFC.

  George.




On Mon, Aug 11, 2014 at 12:09 PM, Dave Goodell (dgoodell) <
dgood...@cisco.com> wrote:

> On Aug 7, 2014, at 11:37 PM, George Bosilca  wrote:
>
> > Paul's tests identified an small issue with the previous patch (a real
> corner-case for ARM v5). The patch below is fixing all known issues.
>
> Wait, why do we care about ARMv5?  It's certainly not a serious HPC
> platform, nor is it even a relevant laptop platform at this point (AFAIK).
>
> -Dave
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15614.php
>

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Dave Goodell (dgoodell)]

On Aug 7, 2014, at 11:37 PM, George Bosilca  wrote:

> Paul's tests identified an small issue with the previous patch (a real 
> corner-case for ARM v5). The patch below is fixing all known issues.

Wait, why do we care about ARMv5?  It's certainly not a serious HPC platform, 
nor is it even a relevant laptop platform at this point (AFAIK).

-Dave

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Hjelm, Nathan Thomas]

I will try to take a look this week and see what I can do.

-Nathan

From: devel [devel-boun...@open-mpi.org] on behalf of George Bosilca 
[bosi...@icl.utk.edu]
Sent: Thursday, August 07, 2014 10:37 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old 
value

Paul's tests identified an small issue with the previous patch (a real 
corner-case for ARM v5). The patch below is fixing all known issues.

Btw, there is still room for volunteers for the .asm work.

  George.



On Tue, Aug 5, 2014 at 2:23 PM, George Bosilca 
<bosi...@icl.utk.edu<mailto:bosi...@icl.utk.edu>> wrote:
Thanks to Paul help all the inlined atomics have been tested. The new patch is 
attached below. However, this only fixes the inline atomics, all those 
generated from the *.asm files have not been updated. Any volunteer?

  George.



On Aug 1, 2014, at 18:09 , Paul Hargrove 
<phhargr...@lbl.gov<mailto:phhargr...@lbl.gov>> wrote:

I have confirmed that George's latest version works on both SPARC ABIs.

ARMv7 and three MIPS ABIs still pending...

-Paul


On Fri, Aug 1, 2014 at 9:40 AM, George Bosilca 
<bosi...@icl.utk.edu<mailto:bosi...@icl.utk.edu>> wrote:
Another version of the atomic patch. Paul has tested it on a bunch of 
platforms. At this point we have confirmation from all architectures except 
SPARC (v8+ and v9).

  George.



On Jul 31, 2014, at 19:13 , George Bosilca 
<bosi...@icl.utk.edu<mailto:bosi...@icl.utk.edu>> wrote:

> All,
>
> Here is the patch that change the meaning of the atomics to make them always 
> return the previous value (similar to sync_fetch_and_<*>). I tested this with 
> the following atomics: OS X, gcc style intrinsics and AMD64.
>
> I did not change the base assembly files used when GCC style assembly 
> operations are not supported. If someone feels like fixing them, feel free.
>
> Paul, I know you have a pretty diverse range computers. Can you try to 
> compile and run a “make check” with the following patch?
>
>  George.
>
> 
>
> On Jul 30, 2014, at 15:21 , Nathan Hjelm 
> <hje...@lanl.gov<mailto:hje...@lanl.gov>> wrote:
>
>>
>> That is what I would prefer. I was trying to not disturb things too
>> much :). Please bring the changes over!
>>
>> -Nathan
>>
>> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
>>>  Why do you want to add new versions? This will lead to having two, almost
>>>  identical, sets of atomics that are conceptually equivalent but different
>>>  in terms of code. And we will have to maintained both!
>>>  I did a similar change in a fork of OPAL in another project but instead of
>>>  adding another flavor of atomics, I completely replaced the available ones
>>>  with a set returning the old value. I can bring the code over.
>>>George.
>>>
>>>  On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove 
>>> <phhargr...@lbl.gov<mailto:phhargr...@lbl.gov>> wrote:
>>>
>>>On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm 
>>> <hje...@lanl.gov<mailto:hje...@lanl.gov>> wrote:
>>>
>>>  Is there a reason why the
>>>  current implementations of opal atomics (add, cmpset) do not return
>>>  the
>>>  old value?
>>>
>>>Because some CPUs don't implement such an atomic instruction?
>>>
>>>On any CPU one *can* certainly synthesize the desired operation with an
>>>added read before the compare-and-swap to return a value that was
>>>present at some time before a failed cmpset.  That is almost certainly
>>>sufficient for your purposes.  However, the added load makes it
>>>(marginally) more expensive on some CPUs that only have the native
>>>equivalent of gcc's __sync_bool_compare_and_swap().

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

Paul's tests identified an small issue with the previous patch (a real
corner-case for ARM v5). The patch below is fixing all known issues.

Btw, there is still room for volunteers for the .asm work.

  George.



On Tue, Aug 5, 2014 at 2:23 PM, George Bosilca  wrote:

> Thanks to Paul help all the inlined atomics have been tested. The new
> patch is attached below. However, this only fixes the inline atomics, all
> those generated from the *.asm files have not been updated. Any volunteer?
>
>   George.
>
>
>
> On Aug 1, 2014, at 18:09 , Paul Hargrove  wrote:
>
> I have confirmed that George's latest version works on both SPARC ABIs.
>
> ARMv7 and three MIPS ABIs still pending...
>
> -Paul
>
>
> On Fri, Aug 1, 2014 at 9:40 AM, George Bosilca 
> wrote:
>
>> Another version of the atomic patch. Paul has tested it on a bunch of
>> platforms. At this point we have confirmation from all architectures except
>> SPARC (v8+ and v9).
>>
>>   George.
>>
>>
>>
>> On Jul 31, 2014, at 19:13 , George Bosilca  wrote:
>>
>> > All,
>> >
>> > Here is the patch that change the meaning of the atomics to make them
>> always return the previous value (similar to sync_fetch_and_<*>). I tested
>> this with the following atomics: OS X, gcc style intrinsics and AMD64.
>> >
>> > I did not change the base assembly files used when GCC style assembly
>> operations are not supported. If someone feels like fixing them, feel free.
>> >
>> > Paul, I know you have a pretty diverse range computers. Can you try to
>> compile and run a “make check” with the following patch?
>> >
>> >  George.
>> >
>> > 
>> >
>> > On Jul 30, 2014, at 15:21 , Nathan Hjelm  wrote:
>> >
>> >>
>> >> That is what I would prefer. I was trying to not disturb things too
>> >> much :). Please bring the changes over!
>> >>
>> >> -Nathan
>> >>
>> >> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
>> >>>  Why do you want to add new versions? This will lead to having two,
>> almost
>> >>>  identical, sets of atomics that are conceptually equivalent but
>> different
>> >>>  in terms of code. And we will have to maintained both!
>> >>>  I did a similar change in a fork of OPAL in another project but
>> instead of
>> >>>  adding another flavor of atomics, I completely replaced the
>> available ones
>> >>>  with a set returning the old value. I can bring the code over.
>> >>>George.
>> >>>
>> >>>  On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove 
>> wrote:
>> >>>
>> >>>On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm 
>> wrote:
>> >>>
>> >>>  Is there a reason why the
>> >>>  current implementations of opal atomics (add, cmpset) do not
>> return
>> >>>  the
>> >>>  old value?
>> >>>
>> >>>Because some CPUs don't implement such an atomic instruction?
>> >>>
>> >>>On any CPU one *can* certainly synthesize the desired operation
>> with an
>> >>>added read before the compare-and-swap to return a value that was
>> >>>present at some time before a failed cmpset.  That is almost
>> certainly
>> >>>sufficient for your purposes.  However, the added load makes it
>> >>>(marginally) more expensive on some CPUs that only have the native
>> >>>equivalent of gcc's __sync_bool_compare_and_swap().
>>
>


atomics.patch
Description: Binary data

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

Thanks to Paul help all the inlined atomics have been tested. The new patch is attached below. However, this only fixes the inline atomics, all those generated from the *.asm files have not been updated. Any volunteer?  George.

atomics.patch
Description: Binary data
On Aug 1, 2014, at 18:09 , Paul Hargrove  wrote:I have confirmed that George's latest version works on both SPARC ABIs.ARMv7 and three MIPS ABIs still pending...-PaulOn Fri, Aug 1, 2014 at 9:40 AM, George Bosilca  wrote:Another version of the atomic patch. Paul has tested it on a bunch of platforms. At this point we have confirmation from all architectures except SPARC (v8+ and v9).  George.On Jul 31, 2014, at 19:13 , George Bosilca  wrote:> All,>> Here is the patch that change the meaning of the atomics to make them always return the previous value (similar to sync_fetch_and_<*>). I tested this with the following atomics: OS X, gcc style intrinsics and AMD64.>> I did not change the base assembly files used when GCC style assembly operations are not supported. If someone feels like fixing them, feel free.>> Paul, I know you have a pretty diverse range computers. Can you try to compile and run a “make check” with the following patch?>>  George.>> >> On Jul 30, 2014, at 15:21 , Nathan Hjelm  wrote:> That is what I would prefer. I was trying to not disturb things too>> much :). Please bring the changes over! -Nathan On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:>>>  Why do you want to add new versions? This will lead to having two, almost>>>  identical, sets of atomics that are conceptually equivalent but different>>>  in terms of code. And we will have to maintained both!>>>  I did a similar change in a fork of OPAL in another project but instead of>>>  adding another flavor of atomics, I completely replaced the available ones>>>  with a set returning the old value. I can bring the code over.>>>    George.>>  On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove  wrote:>>    On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm  wrote:>>      Is there a reason why the>>>      current implementations of opal atomics (add, cmpset) do not return>>>      the>>>      old value?>>    Because some CPUs don't implement such an atomic instruction?>>    On any CPU one *can* certainly synthesize the desired operation with an>>>    added read before the compare-and-swap to return a value that was>>>    present at some time before a failed cmpset.  That is almost certainly>>>    sufficient for your purposes.  However, the added load makes it>>>    (marginally) more expensive on some CPUs that only have the native>>>    equivalent of gcc's __sync_bool_compare_and_swap().>>    -Paul>>>    -->>>    Paul H. Hargrove                          phhargr...@lbl.gov>>>    Future Technologies Group>>>    Computer and Data Sciences Department     Tel: +1-510-495-2352>>>    Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900>>>    ___>>>    devel mailing list>>>    de...@open-mpi.org>>>    Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel>>>    Link to this post:>>>    http://www.open-mpi.org/community/lists/devel/2014/07/15328.php> ___>>> devel mailing list>>> de...@open-mpi.org>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel>>> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15369.php ___>> devel mailing list>> de...@open-mpi.org>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel>> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15370.php>___devel mailing listde...@open-mpi.orgSubscription: http://www.open-mpi.org/mailman/listinfo.cgi/develLink to this post: http://www.open-mpi.org/community/lists/devel/2014/08/15462.php-- Paul H. Hargrove                          phhargr...@lbl.govFuture Technologies GroupComputer and Data Sciences Department     Tel: +1-510-495-2352Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900___devel mailing listde...@open-mpi.orgSubscription: http://www.open-mpi.org/mailman/listinfo.cgi/develLink to this post: http://www.open-mpi.org/community/lists/devel/2014/08/15465.php

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

I have confirmed that George's latest version works on both SPARC ABIs.

ARMv7 and three MIPS ABIs still pending...

-Paul


On Fri, Aug 1, 2014 at 9:40 AM, George Bosilca  wrote:

> Another version of the atomic patch. Paul has tested it on a bunch of
> platforms. At this point we have confirmation from all architectures except
> SPARC (v8+ and v9).
>
>   George.
>
>
>
> On Jul 31, 2014, at 19:13 , George Bosilca  wrote:
>
> > All,
> >
> > Here is the patch that change the meaning of the atomics to make them
> always return the previous value (similar to sync_fetch_and_<*>). I tested
> this with the following atomics: OS X, gcc style intrinsics and AMD64.
> >
> > I did not change the base assembly files used when GCC style assembly
> operations are not supported. If someone feels like fixing them, feel free.
> >
> > Paul, I know you have a pretty diverse range computers. Can you try to
> compile and run a "make check" with the following patch?
> >
> >  George.
> >
> > 
> >
> > On Jul 30, 2014, at 15:21 , Nathan Hjelm  wrote:
> >
> >>
> >> That is what I would prefer. I was trying to not disturb things too
> >> much :). Please bring the changes over!
> >>
> >> -Nathan
> >>
> >> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
> >>>  Why do you want to add new versions? This will lead to having two,
> almost
> >>>  identical, sets of atomics that are conceptually equivalent but
> different
> >>>  in terms of code. And we will have to maintained both!
> >>>  I did a similar change in a fork of OPAL in another project but
> instead of
> >>>  adding another flavor of atomics, I completely replaced the available
> ones
> >>>  with a set returning the old value. I can bring the code over.
> >>>George.
> >>>
> >>>  On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove 
> wrote:
> >>>
> >>>On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm 
> wrote:
> >>>
> >>>  Is there a reason why the
> >>>  current implementations of opal atomics (add, cmpset) do not
> return
> >>>  the
> >>>  old value?
> >>>
> >>>Because some CPUs don't implement such an atomic instruction?
> >>>
> >>>On any CPU one *can* certainly synthesize the desired operation
> with an
> >>>added read before the compare-and-swap to return a value that was
> >>>present at some time before a failed cmpset.  That is almost
> certainly
> >>>sufficient for your purposes.  However, the added load makes it
> >>>(marginally) more expensive on some CPUs that only have the native
> >>>equivalent of gcc's __sync_bool_compare_and_swap().
> >>>
> >>>-Paul
> >>>--
> >>>Paul H. Hargrove  phhargr...@lbl.gov
> >>>Future Technologies Group
> >>>Computer and Data Sciences Department Tel: +1-510-495-2352
> >>>Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> >>>___
> >>>devel mailing list
> >>>de...@open-mpi.org
> >>>Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>Link to this post:
> >>>http://www.open-mpi.org/community/lists/devel/2014/07/15328.php
> >>
> >>> ___
> >>> devel mailing list
> >>> de...@open-mpi.org
> >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15369.php
> >>
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15370.php
> >
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15462.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

MIPS32, MIPS64 and ARMv7 tests are also pending.
-Paul


On Fri, Aug 1, 2014 at 9:40 AM, George Bosilca  wrote:

> Another version of the atomic patch. Paul has tested it on a bunch of
> platforms. At this point we have confirmation from all architectures except
> SPARC (v8+ and v9).
>
>   George.
>
>
>
> On Jul 31, 2014, at 19:13 , George Bosilca  wrote:
>
> > All,
> >
> > Here is the patch that change the meaning of the atomics to make them
> always return the previous value (similar to sync_fetch_and_<*>). I tested
> this with the following atomics: OS X, gcc style intrinsics and AMD64.
> >
> > I did not change the base assembly files used when GCC style assembly
> operations are not supported. If someone feels like fixing them, feel free.
> >
> > Paul, I know you have a pretty diverse range computers. Can you try to
> compile and run a "make check" with the following patch?
> >
> >  George.
> >
> > 
> >
> > On Jul 30, 2014, at 15:21 , Nathan Hjelm  wrote:
> >
> >>
> >> That is what I would prefer. I was trying to not disturb things too
> >> much :). Please bring the changes over!
> >>
> >> -Nathan
> >>
> >> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
> >>>  Why do you want to add new versions? This will lead to having two,
> almost
> >>>  identical, sets of atomics that are conceptually equivalent but
> different
> >>>  in terms of code. And we will have to maintained both!
> >>>  I did a similar change in a fork of OPAL in another project but
> instead of
> >>>  adding another flavor of atomics, I completely replaced the available
> ones
> >>>  with a set returning the old value. I can bring the code over.
> >>>George.
> >>>
> >>>  On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove 
> wrote:
> >>>
> >>>On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm 
> wrote:
> >>>
> >>>  Is there a reason why the
> >>>  current implementations of opal atomics (add, cmpset) do not
> return
> >>>  the
> >>>  old value?
> >>>
> >>>Because some CPUs don't implement such an atomic instruction?
> >>>
> >>>On any CPU one *can* certainly synthesize the desired operation
> with an
> >>>added read before the compare-and-swap to return a value that was
> >>>present at some time before a failed cmpset.  That is almost
> certainly
> >>>sufficient for your purposes.  However, the added load makes it
> >>>(marginally) more expensive on some CPUs that only have the native
> >>>equivalent of gcc's __sync_bool_compare_and_swap().
> >>>
> >>>-Paul
> >>>--
> >>>Paul H. Hargrove  phhargr...@lbl.gov
> >>>Future Technologies Group
> >>>Computer and Data Sciences Department Tel: +1-510-495-2352
> >>>Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> >>>___
> >>>devel mailing list
> >>>de...@open-mpi.org
> >>>Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>Link to this post:
> >>>http://www.open-mpi.org/community/lists/devel/2014/07/15328.php
> >>
> >>> ___
> >>> devel mailing list
> >>> de...@open-mpi.org
> >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15369.php
> >>
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15370.php
> >
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15462.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

Another version of the atomic patch. Paul has tested it on a bunch of 
platforms. At this point we have confirmation from all architectures except 
SPARC (v8+ and v9).

  George.



atomics.patch
Description: Binary data

On Jul 31, 2014, at 19:13 , George Bosilca  wrote:

> All,
> 
> Here is the patch that change the meaning of the atomics to make them always 
> return the previous value (similar to sync_fetch_and_<*>). I tested this with 
> the following atomics: OS X, gcc style intrinsics and AMD64.
> 
> I did not change the base assembly files used when GCC style assembly 
> operations are not supported. If someone feels like fixing them, feel free.
> 
> Paul, I know you have a pretty diverse range computers. Can you try to 
> compile and run a “make check” with the following patch?
> 
>  George.
> 
> 
> 
> On Jul 30, 2014, at 15:21 , Nathan Hjelm  wrote:
> 
>> 
>> That is what I would prefer. I was trying to not disturb things too
>> much :). Please bring the changes over!
>> 
>> -Nathan
>> 
>> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
>>>  Why do you want to add new versions? This will lead to having two, almost
>>>  identical, sets of atomics that are conceptually equivalent but different
>>>  in terms of code. And we will have to maintained both!
>>>  I did a similar change in a fork of OPAL in another project but instead of
>>>  adding another flavor of atomics, I completely replaced the available ones
>>>  with a set returning the old value. I can bring the code over.
>>>George.
>>> 
>>>  On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove  wrote:
>>> 
>>>On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm  wrote:
>>> 
>>>  Is there a reason why the
>>>  current implementations of opal atomics (add, cmpset) do not return
>>>  the
>>>  old value?
>>> 
>>>Because some CPUs don't implement such an atomic instruction?
>>> 
>>>On any CPU one *can* certainly synthesize the desired operation with an
>>>added read before the compare-and-swap to return a value that was
>>>present at some time before a failed cmpset.  That is almost certainly
>>>sufficient for your purposes.  However, the added load makes it
>>>(marginally) more expensive on some CPUs that only have the native
>>>equivalent of gcc's __sync_bool_compare_and_swap().
>>> 
>>>-Paul
>>>--
>>>Paul H. Hargrove  phhargr...@lbl.gov
>>>Future Technologies Group
>>>Computer and Data Sciences Department Tel: +1-510-495-2352
>>>Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>>>___
>>>devel mailing list
>>>de...@open-mpi.org
>>>Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>Link to this post:
>>>http://www.open-mpi.org/community/lists/devel/2014/07/15328.php
>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post: 
>>> http://www.open-mpi.org/community/lists/devel/2014/07/15369.php
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15370.php
> 

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Kawashima, Takahiro]

George,

I compiled trunk with your patch for SPARCV9/Linux/GCC.
I see following warning/errors.


In file included from opal/include/opal/sys/atomic.h:175,
 from opal/asm/asm.c:21:
opal/include/opal/sys/sparcv9/atomic.h:213:1: warning: 
"OPAL_HAVE_ATOMIC_SWAP_64" redefined
opal/include/opal/sys/sparcv9/atomic.h:47:1: warning: this is the location of 
the previous definition

In file included from opal/asm/asm.c:21:
opal/include/opal/sys/atomic.h:369: error: conflicting types for 
'opal_atomic_cmpset_acq_64'
opal/include/opal/sys/sparcv9/atomic.h:175: error: previous definition of 
'opal_atomic_cmpset_acq_64' was here
opal/include/opal/sys/atomic.h:375: error: conflicting types for 
'opal_atomic_cmpset_rel_64'
opal/include/opal/sys/sparcv9/atomic.h:187: error: previous definition of 
'opal_atomic_cmpset_rel_64' was here


The attached patch fixes these warning/errors.

I run test programs only in test/asm directory manually
because 'make check' doesn't run under my cross-compiling
environment. They all passed correctly.

P.S.
I cannot reply until the next week if you request me something
because it's COB in Japan now, sorry.

Takahiro Kawashima,
MPI development team,
Fujitsu

> In case someone else want to play with the new atomics here is the most
> up-to-date patch.
> 
>   George.
> 
> 
> 
> On Thu, Jul 31, 2014 at 10:26 PM, Paul Hargrove  wrote:
> 
> > George:
> >
> > Have a failure with your patch applied on PPC64/Linux and gcc-4.4.6:
> >
> > Making all in asm
> > make[2]: Entering directory
> > `/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/BLD/opal/asm'
> >   CC   asm.lo
> > In file included from
> > /home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/asm/asm.c:21:0:
> > /home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/include/opal/sys/atomic.h:374:9:
> > error: conflicting types for 'opal_atomic_cmpset_rel_64'
> > /home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/include/opal/sys/powerpc/atomic.h:214:19:
> > note: previous definition of 'opal_atomic_cmpset_rel_64' was here
> > /home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/include/opal/sys/atomic.h:374:9:
> > warning: 'opal_atomic_cmpset_rel_64' used but never defined [enabled by
> > default]
> > make[2]: *** [asm.lo] Error 1
> >
> >
> > BTW: the patch applied cleanly to trunk except the portion
> > changing opal/include/opal/sys/osx/atomic.h, which does not exist.
> >
> > -Paul
> >
> >
> > On Thu, Jul 31, 2014 at 4:25 PM, George Bosilca 
> > wrote:
> >
> >> Awesome, thanks Paul. When the results will be in we will fix whatever is
> >> needed for these less common architectures.
> >>
> >>   George.
> >>
> >>
> >>
> >> On Thu, Jul 31, 2014 at 7:24 PM, Paul Hargrove 
> >> wrote:
> >>
> >>>
> >>>
> >>> On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove 
> >>> wrote:
> >>>
> 
>  On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca 
>  wrote:
> 
> > Paul, I know you have a pretty diverse range computers. Can you try to
> > compile and run a “make check” with the following patch?
> 
> 
>  I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever
>  subset of those is still supported).
>  The ARM and MIPS system are emulators and take forever to build OMPI.
>  However, I am not even sure how soon I'll get to start this testing.
> 
> >>>
> >>>
> >>> Add SPARC (v8plus and v9) to that list.
--- opal/include/opal/sys/sparcv9/atomic.h.george	2014-08-01 17:33:25.874189000 +0900
+++ opal/include/opal/sys/sparcv9/atomic.h	2014-08-01 18:21:25.316102730 +0900
@@ -170,8 +170,8 @@
 
 #endif /* OPAL_ASSEMBLY_ARCH == OPAL_SPARCV9_64 */
 
-static inline int opal_atomic_cmpset_acq_64( volatile int64_t *addr,
- int64_t oldval, int64_t newval)
+static inline int64_t opal_atomic_cmpset_acq_64( volatile int64_t *addr,
+ int64_t oldval, int64_t newval)
 {
int rc;
 
@@ -182,8 +182,8 @@
 }
 
 
-static inline int opal_atomic_cmpset_rel_64( volatile int64_t *addr,
- int64_t oldval, int64_t newval)
+static inline int64_t opal_atomic_cmpset_rel_64( volatile int64_t *addr,
+ int64_t oldval, int64_t newval)
 {
opal_atomic_wmb();
return opal_atomic_cmpset_64(addr, oldval, newval);
@@ -210,6 +210,7 @@
 
 #if OPAL_ASSEMBLY_ARCH == OPAL_SPARCV9_64
 
+#undef OPAL_HAVE_ATOMIC_SWAP_64
 #define OPAL_HAVE_ATOMIC_SWAP_64 1
 
 static inline int64_t

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

George:

Have a failure with your patch applied on PPC64/Linux and gcc-4.4.6:

Making all in asm
make[2]: Entering directory
`/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/BLD/opal/asm'
  CC   asm.lo
In file included from
/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/asm/asm.c:21:0:
/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/include/opal/sys/atomic.h:374:9:
error: conflicting types for 'opal_atomic_cmpset_rel_64'
/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/include/opal/sys/powerpc/atomic.h:214:19:
note: previous definition of 'opal_atomic_cmpset_rel_64' was here
/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369/opal/include/opal/sys/atomic.h:374:9:
warning: 'opal_atomic_cmpset_rel_64' used but never defined [enabled by
default]
make[2]: *** [asm.lo] Error 1


BTW: the patch applied cleanly to trunk except the portion
changing opal/include/opal/sys/osx/atomic.h, which does not exist.

-Paul


On Thu, Jul 31, 2014 at 4:25 PM, George Bosilca  wrote:

> Awesome, thanks Paul. When the results will be in we will fix whatever is
> needed for these less common architectures.
>
>   George.
>
>
>
> On Thu, Jul 31, 2014 at 7:24 PM, Paul Hargrove  wrote:
>
>>
>>
>> On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove 
>> wrote:
>>
>>>
>>> On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca 
>>> wrote:
>>>
 Paul, I know you have a pretty diverse range computers. Can you try to
 compile and run a "make check" with the following patch?
>>>
>>>
>>> I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever
>>> subset of those is still supported).
>>> The ARM and MIPS system are emulators and take forever to build OMPI.
>>> However, I am not even sure how soon I'll get to start this testing.
>>>
>>
>>
>> Add SPARC (v8plus and v9) to that list.
>>
>>
>>
>> --
>> Paul H. Hargrove  phhargr...@lbl.gov
>>  Future Technologies Group
>> Computer and Data Sciences Department Tel: +1-510-495-2352
>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/07/15411.php
>>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15412.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

Awesome, thanks Paul. When the results will be in we will fix whatever is
needed for these less common architectures.

  George.



On Thu, Jul 31, 2014 at 7:24 PM, Paul Hargrove  wrote:

>
>
> On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove  wrote:
>
>>
>> On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca 
>> wrote:
>>
>>> Paul, I know you have a pretty diverse range computers. Can you try to
>>> compile and run a “make check” with the following patch?
>>
>>
>> I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever
>> subset of those is still supported).
>> The ARM and MIPS system are emulators and take forever to build OMPI.
>> However, I am not even sure how soon I'll get to start this testing.
>>
>
>
> Add SPARC (v8plus and v9) to that list.
>
>
>
> --
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15411.php
>

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove  wrote:

>
> On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca 
> wrote:
>
>> Paul, I know you have a pretty diverse range computers. Can you try to
>> compile and run a "make check" with the following patch?
>
>
> I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever subset
> of those is still supported).
> The ARM and MIPS system are emulators and take forever to build OMPI.
> However, I am not even sure how soon I'll get to start this testing.
>


Add SPARC (v8plus and v9) to that list.



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca  wrote:

> Paul, I know you have a pretty diverse range computers. Can you try to
> compile and run a "make check" with the following patch?


I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever subset
of those is still supported).
The ARM and MIPS system are emulators and take forever to build OMPI.
However, I am not even sure how soon I'll get to start this testing.

-Paul



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

All,

Here is the patch that change the meaning of the atomics to make them always 
return the previous value (similar to sync_fetch_and_<*>). I tested this with 
the following atomics: OS X, gcc style intrinsics and AMD64.

I did not change the base assembly files used when GCC style assembly 
operations are not supported. If someone feels like fixing them, feel free.

Paul, I know you have a pretty diverse range computers. Can you try to compile 
and run a “make check” with the following patch?

  George.



atomics.patch
Description: Binary data


On Jul 30, 2014, at 15:21 , Nathan Hjelm  wrote:

> 
> That is what I would prefer. I was trying to not disturb things too
> much :). Please bring the changes over!
> 
> -Nathan
> 
> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
>>   Why do you want to add new versions? This will lead to having two, almost
>>   identical, sets of atomics that are conceptually equivalent but different
>>   in terms of code. And we will have to maintained both!
>>   I did a similar change in a fork of OPAL in another project but instead of
>>   adding another flavor of atomics, I completely replaced the available ones
>>   with a set returning the old value. I can bring the code over.
>> George.
>> 
>>   On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove  wrote:
>> 
>> On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm  wrote:
>> 
>>   Is there a reason why the
>>   current implementations of opal atomics (add, cmpset) do not return
>>   the
>>   old value?
>> 
>> Because some CPUs don't implement such an atomic instruction?
>> 
>> On any CPU one *can* certainly synthesize the desired operation with an
>> added read before the compare-and-swap to return a value that was
>> present at some time before a failed cmpset.  That is almost certainly
>> sufficient for your purposes.  However, the added load makes it
>> (marginally) more expensive on some CPUs that only have the native
>> equivalent of gcc's __sync_bool_compare_and_swap().
>> 
>> -Paul
>> --
>> Paul H. Hargrove  phhargr...@lbl.gov
>> Future Technologies Group
>> Computer and Data Sciences Department Tel: +1-510-495-2352
>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/07/15328.php
> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15369.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15370.php

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Nathan Hjelm]

That is what I would prefer. I was trying to not disturb things too
much :). Please bring the changes over!

-Nathan

On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
>Why do you want to add new versions? This will lead to having two, almost
>identical, sets of atomics that are conceptually equivalent but different
>in terms of code. And we will have to maintained both!
>I did a similar change in a fork of OPAL in another project but instead of
>adding another flavor of atomics, I completely replaced the available ones
>with a set returning the old value. I can bring the code over.
>  George.
> 
>On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove  wrote:
> 
>  On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm  wrote:
> 
>Is there a reason why the
>current implementations of opal atomics (add, cmpset) do not return
>the
>old value?
> 
>  Because some CPUs don't implement such an atomic instruction?
> 
>  On any CPU one *can* certainly synthesize the desired operation with an
>  added read before the compare-and-swap to return a value that was
>  present at some time before a failed cmpset.  That is almost certainly
>  sufficient for your purposes.  However, the added load makes it
>  (marginally) more expensive on some CPUs that only have the native
>  equivalent of gcc's __sync_bool_compare_and_swap().
> 
>  -Paul
>  --
>  Paul H. Hargrove  phhargr...@lbl.gov
>  Future Technologies Group
>  Computer and Data Sciences Department Tel: +1-510-495-2352
>  Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>  ___
>  devel mailing list
>  de...@open-mpi.org
>  Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>  Link to this post:
>  http://www.open-mpi.org/community/lists/devel/2014/07/15328.php

> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15369.php



pgpUHSVoeg0RH.pgp
Description: PGP signature

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

Why do you want to add new versions? This will lead to having two, almost
identical, sets of atomics that are conceptually equivalent but different
in terms of code. And we will have to maintained both!

I did a similar change in a fork of OPAL in another project but instead of
adding another flavor of atomics, I completely replaced the available ones
with a set returning the old value. I can bring the code over.

  George.



On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove  wrote:

>
> On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm  wrote:
>
>> Is there a reason why the
>> current implementations of opal atomics (add, cmpset) do not return the
>> old value?
>>
>
> Because some CPUs don't implement such an atomic instruction?
>
> On any CPU one *can* certainly synthesize the desired operation with an
> added read before the compare-and-swap to return a value that was present
> at some time before a failed cmpset.  That is almost certainly sufficient
> for your purposes.  However, the added load makes it (marginally) more
> expensive on some CPUs that only have the native equivalent of gcc's
> __sync_bool_compare_and_swap().
>
> -Paul
>
> --
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15328.php
>

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Paul Hargrove]

On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm  wrote:

> Is there a reason why the
> current implementations of opal atomics (add, cmpset) do not return the
> old value?
>

Because some CPUs don't implement such an atomic instruction?

On any CPU one *can* certainly synthesize the desired operation with an
added read before the compare-and-swap to return a value that was present
at some time before a failed cmpset.  That is almost certainly sufficient
for your purposes.  However, the added load makes it (marginally) more
expensive on some CPUs that only have the native equivalent of gcc's
__sync_bool_compare_and_swap().

-Paul

-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] RFC: add atomic compare-and-swap that returns old value

[Nathan Hjelm]

What: Add new versions of opal_atomic_cmpset_* that return the old value
not whether they succeeded.

Why: I plan on adding support for network atomics to the BTL
interface. The compare-and-swap function will return the old value from
the target memory location. In order to implement a similar operation
for shared memory (in vader) I need versions of the opal_atomic_cmset_*
macros that return the old value.

When: If there are no objections I plan on adding these new macros in
about two weeks (Aug 12).


I have one question associated with this RFC. Is there a reason why the
current implementations of opal atomics (add, cmpset) do not return the
old value? cmpset sort of makes sense but I found the semantics of
opal_atomic_add_* confusing (returns the new value).

-Nathan


pgpEsw98yKr9q.pgp
Description: PGP signature