Re: [whatwg/encoding] Make decode() and encodeInto() accept SharedArrayBuffer-backed views (#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` replacement followed by normal code operating on the copy is more efficient that going through a function pointer on a per-byte basis.

Almost certainly.  The safely-racy memcpy isn't as fast as a native memcpy but we can improve it to approach native speed; that is not true for a call-per-byte.

> 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?

There have been no plans for this since plans are driven by need and with SAB being disabled the need hasn't arisen, but I don't think there's any reason in principle we could not do so.

> 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?

I don't know and until the one-compiler-to-rule-them-all reality that we have now it wasn't really an interesting question, as we have had other compilers and indeed other compilers that don't do inline asm at all.  My gut feeling was that it is easier to trust the C++ compiler with a call to a function that it couldn't possibly know anything about than with inline asm that it might try to figure out the meaning of.

Patches welcome, along with proofs that they are adequate to avoid UB :)

> In the case of `TextEncoder.encodeInto()` how terrible an 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?

I don't think I know enough about Rust to have an opinion.  Even in the case of C++ it's not completely certain that we had to go as far as we have with the UB-safe primitives, but we now have every reason to believe that they are safe and that UB will not bite us (when they are used properly).  My gut feeling is that Rust will have exactly the same problems as C++, esp given that rustc uses llvm.

-- 
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-462270577