Stream: git-wasmtime

Topic: wasmtime / issue #7722 Support different atomic ordering ...

Wasmtime GitHub notifications bot (Dec 22 2023 at 16:14):

yorickpeterse opened issue #7722:

Feature

Cranelift has instructions for atomic operations such as atomic_load and atomic_store. These instructions don't give control over the ordering guarantees of the atomic operations. Instead, the documentation states that the operations are always sequentially consistent.

For many operations, sequential consistency is _way_ overkill. For example, if you just have a counter that is incremented by a bunch of threads, and occasionally you just want to see if it's greater than N, relaxed ordering is more than enough.

Benefit

Depending on the needs of the user, control over the atomic ordering guarantees can lead to better performance, especially on platforms that don't already have strong ordering guarantees such as x86.

Implementation

I'm not familiar with the Cranelift internals, so I can't answer this section.

Alternatives

One could simply stomach the cost of sequential consistency, but I doubt this will work in the long term.

Wasmtime GitHub notifications bot (Dec 22 2023 at 16:15):

yorickpeterse commented on issue #7722:

To add context: in https://github.com/inko-lang/inko/issues/674 I'm looking into what it would take to replace my LLVM backend with Cranelift, now that Cranelift has the features it was missing last time I looked into it (e.g. checked integer arithmetic). I use atomic operations in a few places, currently using Acquire/Release and Relaxed (Monotonic in LLVM) for ordering (based on which one is needed). Some of these operations occur frequently, so I _really_ want to avoid the equivalent of SeqCst.

Wasmtime GitHub notifications bot (Dec 22 2023 at 16:15):

yorickpeterse edited issue #7722:

Feature

Cranelift has instructions for atomic operations such as atomic_load and atomic_store. These instructions don't give control over the ordering guarantees of the atomic operations. Instead, the documentation states that the operations are always sequentially consistent.

For many operations, sequential consistency is _way_ overkill. For example, if you just have a counter that is incremented by a bunch of threads, and occasionally you just want to see if it's greater than N, relaxed ordering is more than enough.

Benefit

Depending on the needs of the user, control over the atomic ordering guarantees can lead to better performance, especially on platforms that don't already have strong ordering guarantees such as x86.

Implementation

I'm not familiar with the Cranelift internals, so I can't answer this section.

Alternatives

One could simply stomach the cost of sequential consistency, but I doubt this will work in the long term.

Wasmtime GitHub notifications bot (Dec 22 2023 at 18:42):

bjorn3 commented on issue #7722:

All loads and stores have at least monotonic ordering as data races are not UB in Cranelift IR. Webassembly doesn't make them UB and for security reasons it wouldn't be possible to have data races be UB for Wasmtime's use case either. In fact by default no loads and stores are UB (unless they overwrite parts of the stack managed by Cranelift like the return address or values spilled to the stack by the register allocator). Even accessing unmapped memory isn't UB. You have to explicitly set the notrap flag to make that UB.

Wasmtime GitHub notifications bot (Dec 22 2023 at 18:53):

yorickpeterse commented on issue #7722:

@bjorn3 I'm not sure I'm entirely following here. Are you stating that because of those guarantees, atomic operations can never be anything but the equivalent of SeqCst?

Wasmtime GitHub notifications bot (Dec 22 2023 at 18:58):

bjorn3 commented on issue #7722:

No, loads and stores can't be weaker than LLVM's monotonic operation by default. It very much is possible to introduce orderings between monotonic and seqcst like weak, acquire and release. They just can't be the equivalent of non-atomic loads and stores in LLVM by default though as for those data races are UB.

In any case my reply was in response to:

[...] (Monotonic in LLVM) [...]

Wasmtime GitHub notifications bot (Dec 22 2023 at 19:01):

yorickpeterse commented on issue #7722:

@bjorn3 Ah gotcha, monotonic/relaxed being the minimum is perfectly fine for me at least, as all I need is LLVM's "Monotonic" and "AcquireRelease".

Last updated: Dec 23 2024 at 12:05 UTC