Views on Relaxed Atomics in C++ from Arm’s technical leadership team

Academic research is critical to the semiconductor industry’s continued ability to push the boundaries of what’s possible, which is why, among several other initiatives within the academic and research community, Arm sponsors PhDs under schemes such as EPSRC iCASE. While undertaking their research, many of the students that work at Arm, or are funded by Arm through these schemes, continue to publish their own independent research. This research, unless it is clearly stated, is not endorsed by or supported by Arm in any way.

A recent post by one such student revives an existing proposal that has already been investigated in academic communities (for example here) on the topic of tightening the compilation of C++ Relaxed Atomics towards various architectures.

This proposal was not formally reviewed by Arm or endorsed by anyone at Arm, despite references in its acknowledgement paragraph. It does not change our official position on the matter, which is: Arm believes that today, the cost implications of tightening C++ relaxed atomics outweigh its benefit.

In addition, we thought it would be useful to provide some critical context and factual corrections to the post:

• The characterization in the post of there being "thousands of bug instances related to relaxed atomics accesses" on Arm systems is unfounded – the comparison is not against the C23 specification, but against an, as yet unadopted, proposed tightening of the specification (specifically Section 2.3 as it is understood that this paper otherwise proposes changes which have been ratified). This remark has already been made by others elsewhere, for example here.
• The post cites a performance analysis of the impact of the proposed approach based on a single very old Arm implementation, using a specific set of benchmarks. To be truly representative, analysis would need to be across a wide range of Arm implementations and properly representative set of benchmarks. The analysis would need to consider the performance risk to “super-hot” critical code paths that are using relaxed atomics to achieve performance.
• The post implies that there is some value in having a consistent compilation approach across different architectures, which is not necessary – individual architectures have different approaches for ordering and compilers should be written to use the appropriate tools for their target architecture.

A full and scientifically rigorous analysis of the performance implications of tightening the compilation of C++ Relaxed Atomics would require significant time, cost and engineering resources. In addition, the consequence of the precedent of this to other languages, such as Java, would need to be considered. Given the fact that Arm has not received significant demand for a change of this position from its ecosystem partners, we have no plans to prioritize this sort of analysis at this time.