Above means "before", no? On Wednesday, December 10, 2014 11:46:08 AM UTC+10, Alon Zakai wrote: > > I don't think a rollback like that is feasible. However, the reason > asyncify ends up causing huge code size increases is not relevant to the > emterpreter. Asyncify needs to add a lot of code to handle all the possible > paths to return to a sync call. In the emterpreter, on the other hand, > literally the code is a stream of binary data - we can just jump right in > to wherever we want. No code size increase, in fact it would be smaller > than JS. > > The interpreter can split up a codebase. Everything below a sync call > would need to be interpreted, and everything above could either be > interpreted or run at full speed. Hopefully a codebase could have event > loop management stuff below, and above, performance sensitive things like > pure computation, which are never done in an async matter, and run at full > speed. In that case, perf should be very good. > > - Alon > > > On Tue, Dec 9, 2014 at 4:15 PM, Soeren Balko <[email protected] > <javascript:>> wrote: > >> 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]> 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] <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.
