If wasm "can be almost directly executed", I think one could reasonably expect compile times to be negligible (under ~200ms), for any payload under ~10M, even on a single core.
Perhaps the design of wasm makes that possible, in theory, but the liftoff baseline compiler fails to meet that expectation. @Dan Performance seems to depend heavily on the number of available hardware threads, and is far too poor on machines that only have a few. In short: Single-threaded performance seems abysmal, so that would be the thing to look into. I don't know if it's faster or slower in firefox. I suspect it's comparable, but I don't find it interesting/relevant enough to test. On Tuesday, December 11, 2018 at 1:16:56 PM UTC-5, Alon Zakai wrote: > > The number of cores definitely matters, yeah - that could explain your > results. > > Wasm is sort of in the middle of the options you mentioned, I think. It > can be almost directly executed by the VM, which is what baseline compilers > do, and they can compile at around the speed of the network, so VM compile > times almost don't matter. Wasm was designed to run pretty well on such > baseline compilers, and often it's a factor of 2 or so compared to full > throughput. To reach that full speed, though, yes - you do need a > sophisticated optimizing VM (to do machine-specific register allocation and > so forth), and those compile times can be slower (but, mostly hidden by the > baseline compilers). > > On Mon, Dec 10, 2018 at 11:04 PM Goran Milovanovic <goranm...@gmail.com > <javascript:>> 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 <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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
