Re:A Proposal Fix for C/C++ Relaxed Atomics in Practice
by one_even_prime on Sunday November 05, 2023 @01:58PM
(#38154370)
Not leaving room for a language below C++ is one of C++ core values. The C++ memory model (and its execution model btw) _is_ a GPU memory model. Some of the major GPU vendors are already able to run standards conforming C++ on their GPUs (e.g. AMD via rocm-stdpar, Intel via the onedpl/algorithm header, and nvidia via their nvc++ compiler). The main reason OOTA and RFUB aren't solved problems in C++, is because the trade-offs of sburf-acyclic are at tension with C++ core values.
Given the importance of GPUs on modern computing systems and the time and effort it has taken C++ to get here, I have a hard time imagining any change to the C++ memory model that would regress this support.
Rust is different: it has a different audience and goals, and it has already painted itself into a design corner that prevents it from properly supporting even modern CPU hardware (e.g. Arm CHERI and RISC-V CHERI with 128-bit and 96-bit pointers). A memory model for Rust that is more restrictive than the C++ memory model and which prevents Rust from natively running on more modern hardware like GPUs, could be a valid point in Rust's design space, if these restrictions were to buy Rust programmers simplicity, productivity, or safety.
If so, then these programs are at significant risk of miscompilation on compilers today. Strengthening the standard would mean that this risk continues until compilers are updated.
If not, then the proposal is asking for an (admittedly modest) performance regression to address what might not be a real problem.
Rust doesn't have a formal memory model yet, but the loom tool reports the (1, 1) outcome as not allowed[2]. I also ran it as normal threaded Rust code (not using a model checker) on M1 Max (which in theory is subject to the same miscompilation), and was not able to reproduce the failures as reported in the linked paper[3], but that doesn't mean much, as it's notoriously tricky to observe memory model violations.
In GPU-land, the (1, 1) outcome is allowed, as can be verified in the Vulkan memory model by the Alloy test in the second file of [2]. Neither HLSL nor Metal Shading Language have proper memory models, so it's hard to say, but in general it's fair to expect that anything allowed by the Vulkan memory model can be observed in other GPU implementations.
Perhaps what is called for is a finer gradation of strength, where the author explicitly asks for the guarantees needed, and the compiler inserts the BAL when it's needed, and skips it if not. Already I can see a lot of value in an explicit "unordered" value for ordering, which would be even weaker than relaxed (allowing more compiler optimization).
[1]: https://plv.mpi-sws.org/scfix/paper.pdf
[2]: https://gist.github.com/raphlinus/41d78d04d117ab0ba3b77065b9...
[3]: https://arxiv.org/pdf/2310.12337.pdf