I would like to see the Massive benchmark updated with WASM. The challenge is there are a couple of ways of starting up WebAssembly, so trickier to measure.
On Thursday, March 16, 2017 at 1:41:57 PM UTC-7, [email protected] wrote: > > 1) I observed that Chrome Canary is faster at webassembly startup by about > 1 second as compared to mainline chrome released. > Similar observation for FF (gap is less there though) - FF webassembly > startup is slower than asm.js but nightly has caught up back. > Is it because some extra VM improvement for WASM has been added in canary > and nightly which will land mainline soon? (maybe like using multicore for > parallel parsing or running baseline compiler if module is not already > compiled > Or are mainline browsers supposed to do some extra validations ? > > 2) I am currently reading hacks articles by Lin Clark and Alon regarding > what makes webassembly fast and they are pretty cool. I am getting greedy > by reading Alon's latest article. > > What can a "wasm web developer" do to make the performance even faster > (except storing in indexeddb ) which would across devices like mobiles and > tablets across all browsers (Edge, Chrome FF and hopefully Safari later) ? > Will the following help? > > a)(startup time on second launch) I believe loading cached code(second > time) from indexeddb cannot be made faster by web developer (since the code > is already compiled - it would not be decoded and validated again but just > executed in sandbox) > > b) (startup time on first launch) And First time launch - Avoiding "VM > fully optimizing the code" would be done by browsers and not web developer > I believe. Maybe web developer could use empterpretor white list or plain > JS on first launch and then fallback to fast wasm code when compilation is > done at idle in other cores and store the code in indexeddb for future > launches. But FF two compiler model (when it is out) will make it > unnecessary.. > > c) (startup time/general JS execution) Reduce memory footprints (in case > it helps on low RAM mobile devices) by splitting code in modules (in > indexeddb) and loading only required modules to memory > > d) (general JS execution) Garbage collection cost (from Lin's diagram) > appear to be zero. If that is the case, we may be able to remove plain JS > code from the wasm webworker totally - this would ensure that GC task does > not run at all (even for few milliseconds) in webworker - and main tasks > would get more cpu (but maybe GC would run at idle time only - when > webworker does a context switch from WASM mode to plain JS mode to > communicate with main UI thread) > > e) (general performance) giving very less value of TOTAL_MEMORY (for low > memory footprints on mobile to get better performance) and growing the > memory automatically on need basis(since memory growth incurs zero penalty > in WASM > Avoiding exceptions and minimizing cross call between JS and WASM is clear. > -- 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.
