Asyncify does seem limited in use on large codebases, due to the issues you found. On small stuff it is good. So the asyncify experiment succeeded at least for small things, and I agree we should continue to look for options here.
Generators could be done, if anyone is interested to try that out. It wouldn't work with asm.js currently, but otherwise seems very feasible. The emterpreter is also designed to help with this. It compiles emscripten output to a bytecode. It runs significantly slower, but does allow in principle for sync/async stuff. It also reduces code size as a side effect. Some more work would be needed on the emterpreter to get to that point, but it can compile and execute eveyrthing we have in the test suite - just the sync part would need to be added. I encourage people to experiment with either or both of those options. - Alon On Sat, Dec 6, 2014 at 7:42 PM, Soeren Balko <[email protected]> wrote: > Folks, > > I would like to share some (not necessarily representative) experiences > with the experimental "asyncify" feature. First of all: I really do like > the ingenious idea behind the current implementation. Introducing a > sync-async bridge is dearly needed for many inherently asynchronous > features such as file i/o. Nonetheless, after experimenting with asyncify > for a while, my enthusiasm has somewhat cooled down, reasons for that being > two major issues: > > For one, compile time for the (admittedly very large and complex) legacy > code base I used has multiplied and requires a lot more memory than it used > to. I actually had to provision some hefty 12 GB to the Ubuntu VM that I > run emscription in, in order to let it complete successfully. And secondly, > the resulting code size is absurdly large (despite using -Oz), making > asyncify impractical for me. In fact, I resorted to using the "main loop" > functionality, despite the needed code refactorings. > > I saw that using Javascript generators was contemplated, but considered > too slow. Has the recent Mozilla announcement changed anything in this > assessment? AFAICS, Microsoft is also working on generators support in IE > and I would expect Google (and eventually, also Apple) to follow course. > Obviously, the "yield" functionality of generators would not suffer from > the code bloat and compile time increase of the current asyncify approach > of forcefully unwinding the call stack and reconstructing it upon resume. > Any thoughts? > > 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]. > 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]. For more options, visit https://groups.google.com/d/optout.
