Hello, It would be interesting if you could also time your application in Firefox, which also has a baseline wasm compiler. That may be a useful data point to help us determine what to look into further.
Regards, Dan On Tue, Dec 11, 2018 at 2:04 AM Goran Milovanovic <goranmilov...@gmail.com> wrote: > I'm not really sure what you mean by "hitting a bad case in the VM". Are > you implying that my code could be doing something highly unusual, which V8 > can't really process effectively? This seems highly unlikely, because the > application in question is a pretty typical OpenGL program, that just > renders some fairly primitive textured geometry. I've also tested other, > even smaller/simpler applications, and performance scaling is pretty much > linear, at about 1 second of delay per 1MB of wasm code. > > Looking at the V8 liftoff post in a little more detail, it seems that the > compilation pipeline is highly parallelized, and that their benchmarks were > done on machines that have *at least* 8 hardware threads ... That would > explain their seemingly impressive results, and it would also explain the > lackluster performance I observe, on a machine with only 2 hardware threads. > > On a more general note: I think my notion of what wasm actually is, and > what I can expect it to do, was a little skewed. I was under the impression > that wasm was a hyper efficient IR, that the browser could just trivially > translate into runnable machine code, with negligible performance impact. > However, the more I learn about it, the more it seems like any other IR, > which requires a fairly involved compilation system, which in turn requires > considerable hardware resources to run at interactive speeds. > > On Monday, December 10, 2018 at 7:51:52 PM UTC-5, Alon Zakai wrote: >> >> Interesting, it's possible you're hitting a bad case in the VM then. Can >> you perhaps make a public testcase of your codebase, and we can show it to >> them? >> >> On Sun, Dec 9, 2018 at 11:02 PM Goran Milovanovic <goranm...@gmail.com> >> wrote: >> >>> I'm using the chrome dev tools Network panel to observe relevant events: >>> >>> * At the 1.25 second mark, all the necessary files (wasm, data, js, ...) >>> have been downloaded. >>> * ----- WASM processing seems to happen here (cpu utilization goes up to >>> 100%) ----- >>> * At the 4.25 second mark, emscripten prepares the filesystem, and I can >>> see this by local blob requests for pngs packed in the data file. >>> * My application's main() begins execution, and that's where >>> initialization for my application starts. >>> >>> The "WebAssembly baseline compiler" flag was set to "Default" ... I >>> don't know what that actually means, and there doesn't seem to be a way to >>> know, but just to be sure, I made it explicitly enabled, and it made no >>> difference. >>> >>> When disabled, the processing is slower by an additional 2 seconds, so >>> it would seem that liftoff is providing some benefit, but nothing that >>> resembles the drastic scaling visible in their benchmarks. >>> >>> >>> On Sunday, December 9, 2018 at 6:25:55 PM UTC-5, Alon Zakai wrote: >>>> >>>> A lot of good stuff has happened since April. The main issue has on the >>>> browser side, where things are now a lot better. In particular, baseline >>>> compilers are now common, like V8's Liftoff, >>>> >>>> https://v8.dev/blog/liftoff >>>> >>>> That should be enabled in Chromium 71, but you can confirm in >>>> chrome://flags. (3 seconds for 3.6MB sounds high for Liftoff, so perhaps it >>>> isn't turned on?) >>>> >>>> How are you measuring startup time, btw? Aside from browser compilation >>>> there may be time spend in the download or in the application's startup >>>> code itself. Running browser profilers can help investigate that. >>>> >>>> On Sun, Dec 9, 2018 at 12:30 PM Goran Milovanovic <goranm...@gmail.com> >>>> wrote: >>>> >>>>> I've made a thread back in April, with a similar focus: >>>>> https://groups.google.com/forum/#!searchin/emscripten-discuss/still$20slow%7Csort:date/emscripten-discuss/Ft3UT0PHX_w/gXUMRN4hAgAJ >>>>> >>>>> While somewhat useful, I think that thread was a bit side-tracked, >>>>> because instead of discussing why WASM startup was so slow, we became more >>>>> focused on why startup for WASM was slower than startup for asm.js (which >>>>> was an issue that I wasn't even aware of, until it was mentioned by >>>>> another >>>>> user). It seems that this imbalance was resolved since then, but the >>>>> fundamental issue of slow WASM startup still remains, because now it >>>>> starts >>>>> up about as fast as the old asm.js output, and, if I understood the core >>>>> promises of WASM (as a pre-processed, binary format), it should be >>>>> significantly faster than that. >>>>> >>>>> My wasm file is 3.6M large. I'm using Emscripten 1.38.20 to compile, >>>>> and running on Chromium 71. It takes ~3 seconds for the application to >>>>> start up. >>>>> >>>>> I'm just wondering if this is a problem in the browsers, or in the >>>>> emscripten toolchain, or somewhere else (assuming that's possible), and >>>>> also if there are plans for addressing this in the not too distant future? >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> 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 emscripten-discuss+unsubscr...@googlegroups.com. >>>>> 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 emscripten-discuss+unsubscr...@googlegroups.com. >>> 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 emscripten-discuss+unsubscr...@googlegroups.com. > 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
