Alon, In the emterpreter approach you propose, would the entire stack need to be run by emterpreter? Or could the code be split somehow such that a major (performance-critical) chunk still runs "natively". What I mean is this: what IMHO breaks the current asyncify approach for large, convoluted code bases is the fact that all code paths to an asynchronous function need to be split, causing the massive code bloat I saw. In my case, I've been trying to implement an asynchronous file i/o capability where every so often, we need to asynchronously fetch a chunk of data and mimic a blocking behavior to do so. When we asynchronous satisfy that file read, we speculatively cache data for subsequent reads, aiming to keep the number of asynchronous "break-outs" low. In effect, we rarely ever hit the asynchronous code path and can mostly satisfy file operations from the cached data. Adding to this, a lot of different code paths lead to the asynchronous function, contributing to the aforementioned code bloat.
What I wonder is this: could emterpreter be used in some sort of speculative execution where we (1) first try to run the code natively (i.e., on the browser's JS runtime). Only if we (2) hit an asynchronous function, we "roll back" the state and (3) re-run that code path using emterpreter, which may then mimic the sync-async bridge? I am not entirely sure if (and how) the rollback behavior could be accomplished. Perhaps by immediately exiting the module (i.e., throw an JS exception) when we hit an asynchronous function and then invoke emterpreter with the (preserved) global state (HEAP8 and friends) from there. Again, I don't know how hard that would be, as it would essentially require native JS execution and emterpreter to share the same module (i.e., global state). Generators would definitely be the much cleaner option... On Tuesday, December 9, 2014 10:13:26 AM UTC+10, Alon Zakai wrote: > > 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] > <javascript:>> 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] <javascript:>. >> 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.
