Re: [whatwg/encoding] New TextDecoder.decode() API needed for Wasm multithreading (#172)

> The plan is to remedy this by using UB-safe primitives for accessing shared memory, see https://bugzilla.mozilla.org/show_bug.cgi?id=1225033.

OK, so from C++ a safely-racy load is a call through a function pointer to a JIT-generated function that the C++ compiler never can see into. I wonder if just using the safely-racy `memcpy` followed by normal code operating on the copy is more efficient that going through a function pointer on a per-byte basis.

Is there any plan to provide a Rust crate that provides access to these operations? Is there any plan to provide safely-racy loads and stores of 128-bit SIMD vectors? Is there's a reliable way (inline asm with the right amount of `volatile`) to convince the LLVM optimizer on the C++ or Rust side that the world may have changed between each load without adding the overhead of a function call via function pointer for each load or are these going to continue to have the cost of a function call via function pointer on a per byte basis?

In the case of `TextEncoder.encodeInto()` how terrible and idea would it be to live dangerously and trust that there's no way the Rust compiler could be optimizing bound checks on the assumption that the memory being written to isn't changed by anyone else?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/172#issuecomment-462266857

Received on Monday, 11 February 2019 09:43:13 UTC