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 < > [email protected] <javascript:>> 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 <[email protected] >> <javascript:>> 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 <[email protected]> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/emscripten-discuss/f2f90663-974d-497c-9bbc-b29026483a49%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/emscripten-discuss/f2f90663-974d-497c-9bbc-b29026483a49%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> 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 [email protected] >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/emscripten-discuss/4270df8a-4cfc-4057-b161-1133888cfe1e%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/emscripten-discuss/4270df8a-4cfc-4057-b161-1133888cfe1e%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXbLTCpmpDki6PkEap9iUMswo4S6t5PmXjSfQUySyG%3Duw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXbLTCpmpDki6PkEap9iUMswo4S6t5PmXjSfQUySyG%3Duw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/44705b9e-8295-4c2b-bca5-acfee7199d85%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
