xl: Use C11 builtin atomics if available. #8528
Conversation
|
The IBM CI (XL) build failed! Please review the log, linked below. Gist: https://gist.github.com/87387a129d5df1b5818dd106b4baaf5c |
awlauria
force-pushed
the
remove_ppc_atomics_master
branch
4 times, most recently
from
c8c14b9 to
9b2ef1b
Compare
|
bot:aws:retest |
If unavailable, fallback to gcc builtins. Some configury work was needed to force include stdatomic.h. Currently xl doesn't have it in its search path. Tested with xl V16.1.1. Signed-off-by: Austen Lauria <[email protected]>
awlauria
force-pushed
the
remove_ppc_atomics_master
branch
from
9b2ef1b to
9dd2ce5
Compare
|
I do see a fair sized regression with opal_lifo/opal_fifo make check tests from the current master in-line assembly xl atomics on power9. So adding the WIP label. It would appear that the c11 atomics via xl are not the way to go performance wise. What I can do is allow xl + c11 if explicitly requested in configure, otherwise use the powerpc atomic headers by default. There are xl builtins that may perform just as well/better than the assembly, I'll see if there's any merit to working those in. |
|
For better performance for the lifo/fifo split out the LL/SC atomics as done for AArch64. See #8412 |
|
CAS is not a native concept on Power or AArch64. It can be implemented on top of LL/SC but the the CAS128 implementation of the lifo/fifo used in Open MPI are for avoiding ABA problems. LL/SC on its own is sufficient to avoid ABA. I did one more test with CAS128 with a CPU release (such as the one used in the LL/SC implementation) and even there the pure LL/SC lifo/fifo beat the CAS128 implementation by more than a factor of 2. |
|
Thanks for the tips @hjelmn - I will be working on making those changes today. |
|
Closing for #8649 |
If unavailable, fallback to gcc builtins.
Some configury work was needed to force include
stdatomic.h. Currently xl doesn't have it in its search
path.
Tested with xl V16.1.1.
Signed-off-by: Austen Lauria [email protected]