This repository has been archived by the owner on Apr 30, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
103 lines (84 loc) · 4.85 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
OpenPA v1.0.4
-------------
The goal of this project is to provide an open source, highly-portable
library that provides atomic primitives (and related constructs) for
high performance, concurrent software. This project is a collaboration
between the Mathematics and Computer Science (MCS) division at Argonne
National Laboratory (ANL) and the HDF Group. The code was originally
derived from work on the MPICH2 project.
Project documentation and bug tracking can be found at:
https://trac.mpich.org/projects/openpa/
If you would like to email questions or discuss topics related to OpenPA
you can send mail to opa-discuss@lists.mcs.anl.gov.
Building
--------
If you checked out the project from source control then you will need to
generate configure files and makefiles with autogen.sh:
% ./autogen.sh
Otherwise, the build procedure is basically the same as any other
autoconfiscated software:
% ./configure [configure_args]
% make
% make install
OpenPA does support Microsoft Windows but the build system
infrastructure is unfortunately not yet in place for general use.
Supported Platforms
-------------------
The following header files in the src/primitives directory support the
listed platforms:
opa_gcc_ia64.h - GCC on Intel's IA64 (Itanium) architecture
opa_gcc_intel_32_64.h - GCC (and some GCC-like compilers) on x86 and
x86_64 architectures
opa_gcc_intrinsics.h - GCC on many other platforms. These use compiler
intrinsics which are not always implemented on
every platform
opa_gcc_ppc.h - GCC and IBM's XLC on PowerPC 4xx and 970 systems.
Specifically, this supports the modified-PPC440
processor in IBM's Blue Gene/P supercomputers and most
64-bit PPC machines such as BG/P login nodes and G5
Macs.
opa_gcc_sicortex.h - GCC on SiCortex machines. This is a MIPS 5K based
architecture, so it may work on similar platforms.
opa_gcc_arm.h - GCC on ARMv7 (and later)
opa_nt_intrinsics.h - Windows support. These use compiler intrinsics
available in Microsoft's Visual Studio compiler.
opa_sun_atomic_ops.h - Solaris support. This uses Solaris' built-in
atomic operations library. Tested on a Niagara
(T5240) machine with Solaris (s10s_u4wos_12b).
We also support two pseudo-platforms:
opa_by_lock.h - Used when you specify "--with-atomic-primitives=no" or when
auto-detecting the primitive implementation and lock-based fall
back is selected. This uses pthread mutexes to emulate the
atomic behavior. This option typically has dramatically slower
performance on most platforms where native primitives are
available. You should usually only use it for testing or on
platforms where pthreads are available but no native primitives
are currently implemented. The library initialization function
*must* be called when using this primitives implementation.
opa_unsafe.h - Used when you specify "--with-atomic-primitives=unsafe". This
can be used to improve performance in code that uses OPA already
and is conditionally compiled to be single-threaded without
having to modify said code. It is also potentially useful for
meta-testing to ensure that any threading tests you might have
will catch bugs when you have a broken atomics implementation.
The OPA test suite itself fails spectacularly when compiled this
way. This header can also be used by defining the preprocessor
macro OPA_USE_UNSAFE_PRIMITIVES prior to including
opa_primitives.h.
Known Issues
------------
* One known issue is that the gcc atomic intrinsics aren't supported by
compilers prior to GCC 4.1. In particular the default Mac OS X compiler is
gcc 4.0.1 so these result in a linker error when using this set of
primitives. The good news is that on OSX/Intel we use native inline
assembly anyway, so this isn't a big problem.
* The PGI compilers currently are not supported. There is at least one known
bug in the PGI compiler's handling of of inline assembly for which we are
awaiting a fix from PGI. Once a fixed version of the compiler is available
this issue should be rectified in an upcoming release.
* As mentioned earlier, Windows is supported but the build system is not
yet present.
* We've had reports of trouble with older IA64 machines running GCC 3.2.2.
Unfortunately we don't have access to a machine with this configuration so we
have been unable to debug and fix the problem. Patches and detailed bug
reports on this issue are very welcome.