Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use GCC atomics if no others available #116

Closed
ompiteam opened this issue Oct 1, 2014 · 8 comments
Closed

Use GCC atomics if no others available #116

ompiteam opened this issue Oct 1, 2014 · 8 comments
Assignees
Labels

Comments

@ompiteam
Copy link
Contributor

ompiteam commented Oct 1, 2014

The Debian OMPI maintainers have asked if OMPI can fall back to GCC atomics if a) no others are available, b) we're compiling with GCC, and c) the GCC atomics are available. This would allow Debian to support Open MPI on platforms other than what we have explicit assembly for.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579505

George / Brian -- what do you think?

@ompiteam ompiteam added this to the Open MPI 1.8.4 milestone Oct 1, 2014
@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Imported from trac issue 2495. Created by jsquyres on 2010-07-20T09:26:49, last modified: 2012-03-28T11:47:45

@ompiteam ompiteam added the bug label Oct 1, 2014
@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by jani on 2011-01-07 07:52:03:

This patch was added in ubuntu to at least have openmpi build on ARM. Since it uses gcc builtins it should work on various ARM platforms, but only tested on ARMv7 (the membarrier and the LL/SC and CAS support instructions at least are different between flavours)

With more configure work this could form the basis for a portable gcc/linux backend - with proper checks whether support for 64 bit atomics is supported or not (not on ARM).

The timer part I have yet to figure out in a portable way.

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by jsquyres on 2011-01-07 08:55:21:

FWIW: The ARM guys sent a full patch for ARM support recently -- I just asked Brian/George to look at it yesterday. I just opened https://svn.open-mpi.org/trac/ompi/ticket/2680 specifically about ARM support.

Thanks for reminding me that this ticket exists, though -- George / Brian -- could you also look at this one?

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by mprinz on 2011-01-11 10:34:28:

Replying to [comment:1 jani]:

With more configure work this could form the basis for a portable gcc/linux backend - with proper checks whether support for 64 bit atomics is supported or not (not on ARM).

This would be great and I'd be very interested to have that for Debian, as there are still a lot of arches where OMPI can't be build. There are also other options, such as OpenPA or libatomic-ops, but using the GCC atomics would be of great help despite the fact that they're not the fastest. (So I've heared.)

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by brbarret on 2011-01-19 12:33:07:

The patch isn't suitable for the general case, which would require a bit more work. I generally think the approach is mostly valid (there's still some issues with timers, although those are optional and could probably be implemented over gettimeofday or some such). Unfortunately, I don't have time to do that work, so someone else would have to. I'd stick with the ARM-specific patches in the other ticket to get ARM support.

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by brbarret on 2012-03-28 11:47:45:

1.7 will include support for using GCC builtins for atomic operations. It doesn't help with the timers, still need to think about that a little bit.

@bosilca
Copy link
Member

bosilca commented Nov 24, 2014

The timers fallback to gettimeofday. As nowadays most compilers support atomic operations, it might be time to enable by default such support. I will propose an RFC shortly based on this topic branch

@jsquyres
Copy link
Member

See #285 and #288.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants