WebAssembly bulk memory operations

[Soeren Balko]

Just saw that Chrome has WebAssembly bulk memory operations in beta. Are there any short-term plans to make these available behind a flag in Emscripten?

Thanks,

Soeren

[Thomas Lively]

If you pass -mbulk-memory to emcc while using the LLVM backend, it will automatically lower memcpy, memmove, and memset to use their bulk memory instruction equivalents. That should work today.

The plan is to land conditional segment initialization using memory.init and data.drop instructions in the linker once bulk memory operations ship by default in stable chrome. That will allow emscripten to use threads without separate memory init files.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f2f90663-974d-497c-9bbc-b29026483a49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Soeren Balko]

Thanks for sharing this! I'm generally wondering in what shape the LLVM backend is at this stage. We've so far used Binaryen, but it seems that new WebAssembly features (SIMD, bulk mem ops) are coming to LLVM first. Would you still consider the LLVM-based wasm backend to be experimental? Also, how does it stack up in terms of performance (of the emitted WebAssembly "binary") when compared with Binaryen? 

On Friday, May 17, 2019 at 4:05:40 AM UTC+10, Thomas Lively wrote:

If you pass -mbulk-memory to emcc while using the LLVM backend, it will automatically lower memcpy, memmove, and memset to use their bulk memory instruction equivalents. That should work today.

The plan is to land conditional segment initialization using memory.init and data.drop instructions in the linker once bulk memory operations ship by default in stable chrome. That will allow emscripten to use threads without separate memory init files.

On Wed, May 15, 2019 at 9:56 PM Soeren Balko <soe...@zfaas.com> wrote:

Just saw that Chrome has WebAssembly bulk memory operations in beta. Are there any short-term plans to make these available behind a flag in Emscripten?

Thanks,

Soeren

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Thomas Lively]

We are working quickly toward being able to make the LLVM backend the default. It is just short of feature parity with the fastcomp backend, but as you've noticed, most new feature development is happening with the LLVM backend. I believe the LLVM backend should be ready to use for everything except threads right now, and my impression is that it produces code that is at least as good as fastcomp-produced code, although I'm not sure of the exact status of that. Note that both the LLVM backend and the fastcomp backend use Binaryen to optimize and transform the output code.

On Thu, May 16, 2019 at 4:09 PM Soeren Balko <soe...@zfaas.com> wrote:

Thanks for sharing this! I'm generally wondering in what shape the LLVM backend is at this stage. We've so far used Binaryen, but it seems that new WebAssembly features (SIMD, bulk mem ops) are coming to LLVM first. Would you still consider the LLVM-based wasm backend to be experimental? Also, how does it stack up in terms of performance (of the emitted WebAssembly "binary") when compared with Binaryen? 

On Friday, May 17, 2019 at 4:05:40 AM UTC+10, Thomas Lively wrote:

If you pass -mbulk-memory to emcc while using the LLVM backend, it will automatically lower memcpy, memmove, and memset to use their bulk memory instruction equivalents. That should work today.

The plan is to land conditional segment initialization using memory.init and data.drop instructions in the linker once bulk memory operations ship by default in stable chrome. That will allow emscripten to use threads without separate memory init files.

On Wed, May 15, 2019 at 9:56 PM Soeren Balko <soe...@zfaas.com> wrote:

Just saw that Chrome has WebAssembly bulk memory operations in beta. Are there any short-term plans to make these available behind a flag in Emscripten?

Thanks,

Soeren

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f2f90663-974d-497c-9bbc-b29026483a49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/4270df8a-4cfc-4057-b161-1133888cfe1e%40googlegroups.com.

[Alon Zakai]

Yeah, just to add to that, the comparison here shouldn't be between the LLVM wasm backend and Binaryen, but the wasm backend and fastcomp. Binaryen still shrinks LLVM wasm backend binaries by a significant amount (15% last I checked) - it does a bunch of wasm-specific improvements that LLVM doesn't.

The LLVM wasm backend emits smaller and faster code than fastcomp on almost all benchmarks I track, with some exceptions - like if newer LLVM makes a different inlining decision than fastcomp, that could go either way. It also compiles much much faster in incremental compilation mode. Overall it will be a big improvement, however, some fastcomp-specific features may not work there (like ASYNCIFY, but we are exploring other options there).

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXbLTCpmpDki6PkEap9iUMswo4S6t5PmXjSfQUySyG%3Duw%40mail.gmail.com.

[Soeren Balko]

Thanks, excellent - I will trial the LLVM backend then. Very eager to see what performance improvement I'll see. 

Re Asyncify - I think this has become obsolete with the SharedArrayBuffer + Atomics feature, which lets you implement a wait/notify pattern (ie., pause in a wasm call stack without returning control to the JS event loop). When I tested Asyncify a long time ago, I found the approach interesting, but not really all that practical for a complex code base. In our code, the asm.js binary went up to 5x the size. 

Soeren

On Friday, May 17, 2019 at 12:13:46 PM UTC+10, Alon Zakai wrote:

Yeah, just to add to that, the comparison here shouldn't be between the LLVM wasm backend and Binaryen, but the wasm backend and fastcomp. Binaryen still shrinks LLVM wasm backend binaries by a significant amount (15% last I checked) - it does a bunch of wasm-specific improvements that LLVM doesn't.

The LLVM wasm backend emits smaller and faster code than fastcomp on almost all benchmarks I track, with some exceptions - like if newer LLVM makes a different inlining decision than fastcomp, that could go either way. It also compiles much much faster in incremental compilation mode. Overall it will be a big improvement, however, some fastcomp-specific features may not work there (like ASYNCIFY, but we are exploring other options there).

On Thu, May 16, 2019 at 4:20 PM 'Thomas Lively' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

We are working quickly toward being able to make the LLVM backend the default. It is just short of feature parity with the fastcomp backend, but as you've noticed, most new feature development is happening with the LLVM backend. I believe the LLVM backend should be ready to use for everything except threads right now, and my impression is that it produces code that is at least as good as fastcomp-produced code, although I'm not sure of the exact status of that. Note that both the LLVM backend and the fastcomp backend use Binaryen to optimize and transform the output code.

On Thu, May 16, 2019 at 4:09 PM Soeren Balko <soe...@zfaas.com> wrote:

Thanks for sharing this! I'm generally wondering in what shape the LLVM backend is at this stage. We've so far used Binaryen, but it seems that new WebAssembly features (SIMD, bulk mem ops) are coming to LLVM first. Would you still consider the LLVM-based wasm backend to be experimental? Also, how does it stack up in terms of performance (of the emitted WebAssembly "binary") when compared with Binaryen? 

On Friday, May 17, 2019 at 4:05:40 AM UTC+10, Thomas Lively wrote:

If you pass -mbulk-memory to emcc while using the LLVM backend, it will automatically lower memcpy, memmove, and memset to use their bulk memory instruction equivalents. That should work today.

The plan is to land conditional segment initialization using memory.init and data.drop instructions in the linker once bulk memory operations ship by default in stable chrome. That will allow emscripten to use threads without separate memory init files.

On Wed, May 15, 2019 at 9:56 PM Soeren Balko <soe...@zfaas.com> wrote:

Just saw that Chrome has WebAssembly bulk memory operations in beta. Are there any short-term plans to make these available behind a flag in Emscripten?

Thanks,

Soeren

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f2f90663-974d-497c-9bbc-b29026483a49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/4270df8a-4cfc-4057-b161-1133888cfe1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.